views:

363

answers:

6

I have come up against this problem a few times at inopportune moments:

  • trying to work on open source Java projects with deep paths
  • Storing deep Fitnesse wiki trees in source control
  • An error trying to use Bazaar to import my source control tree

Why does this limit exist?

Why hasn't it been removed yet?

How do you cope with the path limit? ... and no, switching to linux or Mac OS X is not a valid answer to this question ;)

A: 

Backwards compatibility.

This 260 character limit is baked into more placed than just the file system. For example, it is a constant (MAX_PATH) in the Windows API.

Matt
It's not the filesystem that's the real isse, as you can use the Unicode version of CreateFile and a special prefix to create far longer path names, up to 32,767 wide characters. However, most programs don't support it due to the whole MAX_PATH thing, so you'll usually have problems making it work anyway...
Michael Madsen
+3  A: 

Read this article it helps you http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath

valli
A: 

I'm sure Raymond Chen wrote something about this once, but i can't find it anywhere. In any case the popular consensus is that you have 256 bytes for the path, plus four more bytes for either prefixing or suffixing or containing terminating null characters.

slugster
+1  A: 

This is not strictly true as the NTFS filesystem supports paths up to 32k characters. You can use the win32 api and "\?\" prefix the path to use greater than 260 characters.

A detailed explanation of long path from the .Net BCL team blog.
A small excerpt highlights the issue with long paths

Another concern is inconsistent behavior that would result by exposing long path support. Long paths with the \?\ prefix can be used in most of the file-related Windows APIs, but not all Windows APIs. For example, LoadLibrary, which maps a module into the address of the calling process, fails if the file name is longer than MAX_PATH. So this means MoveFile will let you move a DLL to a location such that its path is longer than 260 characters, but when you try to load the DLL, it would fail. There are similar examples throughout the Windows APIs; some workarounds exist, but they are on a case-by-case basis.

Pratik
Fair enough, but it means you have to use P/Invoke in a lot of places and this, to my mind, reduces the portability of your .Net code. What if I wanted to keep Mono-compatibility?
Jeffrey Cameron
My point was that you can use long path if you really wanted to. But I agree that it is a pain and personally I would avoid this as well.
Pratik
A: 

You can mount a folder as as drive. From the command line:

subst x: /path/to/long/folder
jonchang
A: 

OH YES, this problem has been ANNOYING me for years!!

See, it's 2010, not 1995 anymore. People must finally convince their inner self to get rid of their ancient applications!

For example, I had a file system which formerly was on a (now deprecated) drive letter, let' s call it D:\

Now we're on a C:\Mounts\E\ junction, which points to another hard disk.

As my longest path was 249 characters (measured!!), I got huge bunches of error messages when copying ("file does not exist", "pathname too long" etc.) I HATE MICRO$OFT FOR THAT!!!

It costs me up to 3 hours extra to fix these sorts of issues. Drop that fucking limit - now!

andy