tags:

views:

957

answers:

3

We constantly run into this problem...

Example:

if I have a file that I want to copy it into an another directory or UNC share and if the length of the path exceeds 248 (if I am not mistaken), then it throws PathTooLongException. Is there any workaround to this problem?

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

Thank you!

+1  A: 

Take a look at this article:

http://aspadvice.com/blogs/davidwalker/archive/2007/01/22/PathTooLongException-work-around.aspx

I also have an article on my site that shows you how to call CopyFileEx using P/Invoke - TTS

Michael G
I've seen this post before. Unfortunately it didn't resolve the problem we are running into. This article does not address the issue of copying a file to a path that exceeds 248/260 chars.
theKing
Trying to avoid use of win32 API :(
theKing
I don't think there is a way to do it with managed code. .NET uses a ANSI version of the createfile function.
Michael G
the answer routeNpingme posted will probably be your best bet; even if it uses win32 calls.
Michael G
yeah that's what it looks like. Bummer
theKing
+2  A: 

Only 1 workaround that I've seen on this one... this might be helpful

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

routeNpingme
This article or the code itself does not address how you would create a new directory under a path that is already exceeded 260 chars.
theKing
+1  A: 

This has been discussed in depth by the BCL team, see the blog entries

In essence there is no way to do this within .Net code and stick to the BCL. Too many functions rely on being able to canonicalize the path name (which immediately triggers the use of functions expecting MAX_PATH to be obeyed).

You could wrap all the win32 functions that support the "\\?\" syntax, with these you would be able to implement a suite of long path aware functionality but this would be cumbersome.

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

In answer to your specific need I would investigate whether the use of robocopy directly would be sufficient to perform this task.

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

ShuggyCoUk