Path too Long and .NET

Some of you may know the famous error “System.IO.PathTooLongException“.
The path is too long after being fully qualified. Make sure path is less than 260 characters.
This is by design from the Windows API and the .NET Framework.
Naming Files, Paths, and Namespaces:

The Windows API Function CreateFileEx from the Kernel32.dll utilizes Unicode.  By appending the string "\\?\" in front of the path this API Function can handle up to 32,000 characters.

You can list long paths using the \\?\c:\ syntax in cmd.exe!
dir \\?\c:\ /s
PowerShell and cmd.exe:
$foldernames=cmd /c 'dir \\?\c:\ /s /ad |findstr "\\\\?\\"'

The prefix of \\?\ is not supported within .Net at the time of writing (as of version 4.0).
So you can not simply append the string "\\?\" to your normal Path! This will only work with the mentioned Windows Api Function!
Otherwise you will get the error "Illegal characters in path." !

You can try to use the .NET Classes System.IO.Directory.GetFiles() and System.IO.Directory.GetDirectories()
They both return back string arrays of the full path of the files and directories respectively.
As long as you don't need the additional properties, as in this case, this is the easiest solution to the problem.

If you can’t live with that, there is a Project on Codeplex from the .NET Base Class Library (BCL) Team.
The work there is in the conceptual state and there is no further development, but you can use it if you are a .NET Developer:

Read the Blog Post of the BCL Team:
Long Paths in .NET, Part 1 of 3
Long Paths in .NET, Part 2 of 3: Long Path Workarounds
Long Paths in .NET, Part 3 of 3 Redux

There is also a library that encapsulates all this work over at google code called zeta long paths

Use Robocopy as workarround

There is an Article at the PowerShell Magazine that shows how to use Robocopy as a workaround
Parse Robocopy output in PowerShell to find long path names – Workaround for 260 character limit in Windows

In the following example we use Robocopy in the virtual mode with the option /l ($env:Temp is never used) .
The Option /l Specifies that files are to be listed only (and not copied, deleted, or time stamped).
So all work is done only in the Computer memory and not in the File system. This is really fast!
This example is to calculate the size of a folder incl. all sub folders. This works even with long pathes!
The Text output of Robocopy is examined and splited so that PowerShell gets only the amount of bytes.
Text processing is error prone ! You can even use the Robocopy Clone mentioned below!

1.$Ordner = 'c:\program files'
2.(robocopy.exe $Ordner $env:Temp /zb /e /l /r:1 /w:1 /nfl /ndl /nc /fp /bytes /np /njh) | Where-Object {$_ -like "*Bytes*"} | ForEach-Object { (-split $_)[1] }


Use a Share or a substitution as workaround

You can access a Long Path even if you create a Share on a deep point of the Path.
Then you can use the Share to access files which are deeper then that point.
For example if you create a Share or a drive substitution with "Subst" on a Folder, with the depth of 250 characters than you can access the rest of the Path by use of the Share.(But even that may fail)

PowerShell Path too Long and .NET

The MVP Joel 'Jaykul' Bennett picked up the work of the BCL Team and developed a PowerShell Module with a minimalistic set of PowerShell Cmdlets to deal with Long Paths.

PowerShell Robocopy Clone .NET

The MCT Ingo Karstein even picked up the work of the BCL Team and developed a full blown Open source .NET PowerShell Robocopy Clone:
And here on Codeplex

This .NET Robocopy Clone supports even Path length up to 32,000 characters.

See further:

See Also