How to avoid System.IO.PathTooLongException?

Question

We are constantly faced with this problem ...

Example:

If I have a file that I want to copy to another directory or UNC share, and if the path length exceeds 248 (if I'm not mistaken), then it throws a PathTooLongException. Is there any workaround?

PS: Is there any registry setting to set this path for a longer char?

Answer 1

As described in the Jeremy Kuhne blog , the .NET Framework 4.6.2 removes MAX_PATH where possible without breaking backward compatibility.

Answer 2

Try the following: Delimon.Win32.IO library (V4.0) . This Libarary is written in .NET Framework 4.0

Delimon.Win32.IO replaces the basic file functions of System.IO and supports file and folder names up to 32,767 .

https://gallery.technet.microsoft.com/DelimonWin32IO-Library-V40-7ff6b16c

This library is written specifically to overcome the limitations of the .NET Framework for using the long path and file names. Using this library, you can programmatically browse, access, write, delete, etc. Files and folders that are not available in the System.IO.Library namespace

Using

• First add the link to the Delimon.Win32.IO.dll file to your project (Go to the Delimon.Win32.IO.dll file)

• In your code file add "using Delimon.Win32.IO"

• Use regular File and Directory objects as if you were working with System.IO

Answer 3

This is discussed in detail by the BCL team, see notes

In essence, there is no way to do this in .Net code and adhere to BCL. Too many functions rely on the ability to canonicalize a path name (which immediately starts using functions that are waiting for MAX_PATH to execute).

You can wrap all win32 functions that support the "\\? \" Syntax, with which you can implement a set of functions with a long path, but this will be cumbersome.

Since a huge number of tools (including explorer [1]) cannot process long path names, it is not recommended to go along this route unless you are happy that all interaction with the resulting file system goes through your library (or a limited number of tools that built to handle it like robocopy)

In response to your specific needs, I would investigate whether using robocopy directly would be sufficient to complete this task.

[1] Vista has ways to alleviate the problem with some fancy renaming under the hood, but this is fragile at best)

Answer 4

Only one workaround I've seen on this ... this might be useful

http://www.codeproject.com/KB/files/LongFileNames.aspx

Answer 5

The problem is the ANSI versions of the Windows API. One solution that needs to be thoroughly tested is to force the use of Unicode versions of the Windows API. This can be done by adding " \\?\ " To the requested path.

More information, including information about work, can be found in the following blog posts from the Microsoft Base Class Library (BCL) called Long Paths in .NET:

• http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx
• http://blogs.msdn.com/bclteam/archive/2007/03/26/long-paths-in-net-part-2-of-3-long-path-workarounds-kim-hamilton.aspx
• http://blogs.msdn.com/b/bclteam/archive/2008/07/07/long-paths-in-net-part-3-of-3-redux-kim-hamilton.aspx

Answer 6

I used the subst command to get around the problem ... http://www.techrepublic.com/article/mapping-drive-letters-to-local-folders-in-windows-xp/5975262

Answer 7

In C #, for me this is a workaround:

 /*make long path short by setting it to like cd*/ string path = @"\\godDamnLong\Path\"; Directory.SetCurrentDirectory(path); 

Answer 8

This library may be useful: Zeta Long Paths