Long path support
PowerShell really needs to be able to handle long paths.
It is really tedious having to drop out to RoboCopy to enumerate/copy/etc. files with more than 260 character paths.
We all know that these paths exist on our file servers etc., yet core support for them in various bits of Windows (including the newer ones like PowerShell) still seems to be lacking.
Long file paths are now supported in Windows 10 Anniversary Update! Get more info on how to enable them here; https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/
Jason Fossen commented
It's great that optional support has been added, it's a hard bug to squash with a long history. But when will a future version of the .NET Framework or WMF enable it by default? To rely on it consistently requires that it be enabled by default, at least for a particular platform. Thanks!
Jesse Marquart commented
So rather than having to wait for the next iteration of .Net and PowerShell which will hopefully resolve this issue can we can some kind of built in module or function for this in the interim?
For example something like the following using junction/symbolic links to work around the issue, but as a built in PowerShell function or module (see post below):
Circumvent the 260 MAX_LENGTH path in PowerShell with junctions
Juho Lehto commented
You can work around these limitations using AlphaFS. http://alphafs.alphaleonis.com/
PowerShell examples: https://github.com/alphaleonis/AlphaFS/wiki/PowerShell
This isn't a powershell limitation, it is a .Net limitation so .Net has to be fixed first. I know some efforts were made in the BCL to address it but I don't know if anything has made it to .Net core...