
Fix 260 character file name length limitation: Declined - cryptos
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2156195-fix-260-character-file-name-length-limitation
======
chao-
I was made aware of this artificial limitation through a pretty vivid edge
case while I a student some years ago. TortoiseSVN had somehow borked and
began to recursively create .svn directories inside of each other, as fast as
it could, until such time as I managed to kill the process.

Many can guess what happened next: I went to delete the erroneous top-level
.svn folder and was given an error, the gist of which was: "Cannot remove.
Path too long." There's more to the story, but it turns out the real answer
was to boot into a Linux LiveCD and delete from within there.

I found it strange that one set of Win32 calls allowed TortoiseSVN to _create_
paths of a certain depth, but the other set, used by Microsoft in their tools,
would not allow me to delete them. These days I understand the reasons behind
it, and so instead find it merely annoying.

~~~
qwerta
NTFS has actual support for hard file links, but only usage I ever seen was
for jokes similar to this one.

~~~
Aloha
I use junction/hard links to alias part of my filesystem into dropbox. There
is a real use case for it.

------
PaulHoule
Unfortunately this kind of thing is the reason why Windows is in a death
spiral that it probably won't get out of.

Microsoft has had many chances to introduce clean new APIs: for instance, .NET
could have been built on top of a simpler platform, or Metro could have been
an opportunity to take out some cruft.

In the end Metro breaks everything (if you think the median programmer could
write non-trivial apps with asynchronous I/O, think again.) Amazingly, Metro
almost feels like a tablet operating system when it is running on top of the
line hardware, but the ultimate attack on latency is to remove things from the
stack and not to add them.

Personally I think Windows today (even Win 8) beats the pants off Linux and
MacOS as a GUI operating system, but I seriously have to ask questions such as
"will Intel be making new x86-compatible processors 10 years from now?" when I
see Microsoft and Intel consistently painting themselves in a corner.

~~~
gaius
It shouldn't matter. NT was designed to be platform agnostic; it was written
on the Intel i960, a long-forgotten RISC processor from Intel, by guys who had
cut their teeth on VAX and Alpha, and was released on x86, Alpha, MIPS and
PPC. There was even a SPARC port which never saw general release. I was
running SQL Server on NT on Alpha in '96 or thenabouts, and bloody quick it
was too! Porting NT 7 (or whatever Windows 8 really is) to ARM or POWER or
whatever is not going to be a big deal.

~~~
masklinn
> Porting NT 7 (or whatever Windows 8 really is) to ARM or POWER or whatever
> is not going to be a big deal.

I'm uncertain they kept cross-platform systems running around (whereas I'm
reasonably certain Apple has a full OSX running on ARM internally, as they had
OSX/x86 long before they left POWER behind). Although NT was built to support
a number of architectures, it's been almost 15 years since NT last ran on
non-x86 systems (AlphaNT, the Alpha port of Windows 2000; MIPS and PPC had
already been dropped by this time), that's a very long time, and more than
enough for x86 dependencies to creep in.

On the other hand, WinRT is supposedly a full NT kernel on ARM, so...

~~~
koenigdavidmj
Windows through Server 2008 ran on Itanium, so they've been fine with non-x86
at least up until that point.

~~~
tanzam75
The Itanium build continued through Server 2008 R2.

Thus, _every_ version of Windows NT has been released on at least one non-x86
platform.

\- NT 3.1-3.5: x86, Alpha, MIPS

\- NT 4.0: x86, Alpha, MIPS, PowerPC

\- 2000 through 2008 R2 (7.0): x86, Itanium

\- 2012 (8.0): x86, ARM

~~~
Camillo
2012 is actually NT 6.2 (as is Windows 8).

~~~
tanzam75
> _2012 is actually NT 6.2 (as is Windows 8)._

Notice that I listed Windows Server 2008 R2 as 7.0 rather than as 6.1. And
that I listed Windows 2000 as 2000, rather than as 5.0.

In other words, I was giving the equivalent workstation OS -- not the internal
NT version number.

------
jonchang
[http://msdn.microsoft.com/en-
us/library/aa365247%28VS.85%29....](http://msdn.microsoft.com/en-
us/library/aa365247%28VS.85%29.aspx#maxpath)

[http://stackoverflow.com/questions/1880321/why-does-
the-260-...](http://stackoverflow.com/questions/1880321/why-does-
the-260-character-path-length-limit-exist-in-windows/)

[http://www.codinghorror.com/blog/2006/11/filesystem-paths-
ho...](http://www.codinghorror.com/blog/2006/11/filesystem-paths-how-long-is-
too-long.html)

Summary: The assumption has been baked in forever and changing it is Non-
Trivial. Workarounds exist though! (Kind of.)

~~~
EdwardDiego
Yep, our Maven project routinely fails to build on Windows as there are some
paths which are just too long.

------
svachalek
The "forever" in the title does not exist in the linked response, and I would
also note that the question seems to be in regards to Visual Studio and has a
very VS-oriented response.

Some Windows APIs support 32k paths but since not all do, very few
applications can claim to support more than 260.

------
throwaway9101
> gets in the way of having a deeply-nested project hierarchy"

Do people actually want deeply-nested project hierarchies?

For example, from a real-world, full operating system, the deepest path I can
find[0] is in a build directory and 184 characters:

> "./ports/lang/python26/work/Python-2.6.1/portbld.static/build/temp.XXXXXX
> XXXXX-vHEAD-amd64-2.6/XXXXXX-
> home/XXXXX.git/src/ports/lang/python26/work/Python-2.6.1/Modules/_multiprocessing"

(Names changed to protect the "innocent.")

[0]:

    
    
        $ mkfifo ../names
        $ find . > ../names &
        $ python
        >>> with open("../names") as f:
        ...   l = 0
        ...   nm = None
        ...   for n in f.readlines():
        ...     if len(n) > l: l, nm = len(n), n
        ...   print l, nm

~~~
badman_ting
Right now, sure. But suppose some piece of software goes rogue and starts
creating dirs and files. Further suppose that there's enough of them to fill
the disk. OK, now your disk is full and nothing on the machine works, so you
need to delete those deeply-nested files. Except, whoops!, the paths are too
long, so you can't delete them with the command line. OK, now you're writing a
script or burning some godawful boot CD to try to get to a safe mode or Linux
kernel. All in order to delete some silly unnecessary files.

Problems like this aren't problems when everything is working normally. But
that's beside the point. When the shit hits the fan and the system is only
getting in your way and adding to the problems instead of helping solve them,
it's really really really not fun.

~~~
throwaway9101
I know, when the shit really hits the fan, visual studio is the tool I would
use to try and clean up those messy directories.

</sarcasm>. The complaint is about Visual Studio's decision in particular, not
the weakness of (some) (old) Win32 APIs.

------
malaporte
Errr, it says Visual Studio will limit the path length for now. Windows
already support longer path names, if you use the right APIs.

My understanding is that it's not worth going over all of their code to use
the newer APIs since they also rely on third parties that they can't force to
update. Those would still break when dealing with longer paths.

Still sucks (the path length limit is indeed problematic, especially when
dealing with Java code), but let's not exagerate things shall we?

~~~
kevin_rubyhouse
I have the same feeling as you... I don't understand where other people's
hostility is coming from. This sounds like it would be a minor change. Will
Buik, who posted the decline note, said that it would affect many products and
features. Besides making those changes, they also have to be rigorously
tested. And then the change may not even be consistent all across the board
because of third-party tools that depend on the 260 character limit
assumption... In the end, Microsoft has limited resources just like every
other company. They have to allocate it in a way that creates the most value
for customers, I'm assuming. Bug fixing and addressing customer complaints is
creating value, but it has to be weighed against other priorities, depending
on the severity.

~~~
mherkender
People are hostile because they're tired of Microsoft holding things back.
These decisions, while reasonable, ultimately don't add up to good decisions.
They're not obligated to do anything else, but I'm not obligated to be nice
about it.

------
mappu
MAX_PATH is a #define, so by increasing it you immediately cause buffer
overflow vulnerabilities in every program which ever does a wchar_t
foo[MAX_PATH] = {0}; since the old limit will be baked into the binaries.

Even if VS restricts itself to 32k-aware APIs, you'll hit this eventually when
shelling out or calling any third-party code. Never going to happen.

~~~
XorNot
Ok I may just be overtired but how would changing a define cause this? Its a
static number - you make it bigger and ordinary programs just can't see the
extra length in buffers. They're not going to be assuming they can execute
memory they didn't allocate, and Windows won't allocate them memory from a
buffer string that's already been handed out.

Even if they're just looking for a null terminator, they'll crash when they
overrun the bounds if written properly.

~~~
mappu
Consider something like

    
    
        wchar_t buff[MAX_PATH] = {0};
        int (*callback)(void);
        
        if (NULL == ::PathCombine(buff, /* ... */)) {
          return; // Error, don't continue
        }
        callback();
    

If this is compiled with a small MAX_PATH and run on a system with a large
MAX_PATH, then the system can write a value that's too long, overflow `buff`
and overwrite `callback`, which would then execute the buffer contents and
probably crash. Building an exploit out of this is left as an exercise for the
reader (e.g. supply PathCombine with some shellcode)

I picked a random API, but there are several win32 functions which accept a
character buffer without an explicit size, and mention MAX_PATH in the MSDN
documentation.

~~~
XorNot
You could patch those functions if you were Microsoft and overload them so
they had a form which worked explicitly with long paths, though I suppose
that's getting beside the point since Windows already has the necessary APIs -
the problem is MS for some reason insists on not transitioning to them.

~~~
jussij
There is nothing to say the developer did not create their own version of that
API function:

    
    
       if (NULL == ::MySpecialPathCombine(buff, /* ... */)) {
          return; // Error, don't continue
       }
    

There is no way Microsoft can patch that, but the problem is still there.

Also back to the PathCombine example. When the third party executable was
compiled, the Windows SDK would have defined PathCombine to take a string the
size of 260 (or whatever value MAX_PATH was at the time it was compiled).

If Microsoft did patch the call and then return more than 260 it would just
crash the calling third party executable as it would only be expecting at most
260 characters.

In effect Microsoft would effectively re-defined the static PathCombine API
signature at runtime and making it some sort of dynamic signature.

------
adandy
Am I the only one that had a response of "OK" to this? While I think this
limitation is so sad it's funny I haven't had problems with it in years.

~~~
mark-r
Check out some of the replies on the page. It seems that under certain not-
rare circumstances, Visual Studio itself will generate paths longer than 260
characters.

------
ianstallings
What's important here is not the bug or how it can be fixed, or worked around.
What's important is the fact that they'd rather create new features than fix
bugs. Now that might be undue, this is a the very definition of an edge case,
but it's just one more nail.. Proving that they'd rather "move forward" than
look back. Not a good image to have. Even if it's just an image.

------
kbar13
oh no, how will my Enterprise Java Enterprise Application work on our Windows
Enterprise Production Enterprise Datacenter Edition?

------
zdrummond
This is a global issue with Windows, not with Visual Studio. If you use these
"new" APIs to write above MAX_PATH [1], the file system will obey you, but
tons of other tools will not. One of these minor tools is Windows
Explorer![2].

So if you updated Visual Studio to support it, a ton of other tooling and UX
would fail. This needs to be a corporate wide, product wide, and 3rd party
initiative. The scale of which is likely not worth the result.

[1] [http://msdn.microsoft.com/en-
us/library/windows/desktop/aa36...](http://msdn.microsoft.com/en-
us/library/windows/desktop/aa365247\(v=vs.85\).aspx)

[2] I don't heavily use Windows anymore, but when I tested < Windows 8
machines with > MAX_PATH, Explorer did not work.

------
w-m
Looking for the longest path on my machine, I was slightly amused to learn it
was this one (length of 345 characters):

/Applications/Xcode.app/Contents/Developer/Documentation/DocSets/com.apple.ADC_Reference_Library.DeveloperTools.4_6.docset/Contents/Resources/Documents/recipes/instruments_help-
stack-trace-
help/Displaying_Your_Source_File_That_Contains_a_the_Symbol_in_a_Stack_Trace/13_Displaying_Your_Source_File_That_Contains_a_the_Symbol_in_a_Stack_Trace.html

------
amadvance
Dear Microsoft, you made thousands of us to suffer the pain to deal with your
API to access long paths.

Please have now at least the decency to do the same without complaining.

------
Already__Taken
I always thought this limitation came from NTFS, or at least a previous
version of.

Maybe this might be resolved in the gradual move to ReFS which I am under the
impression is the long term future of the windows world.

~~~
earlz
NTFS is actually a pretty glorious filesystem. It even includes support for
soft and hard links.. but for some reason Windows doesn't use them and instead
prefers it's weird shortcut file abstraction which never works outside of
Explorer

~~~
ygra
You haven't looked at the default filesystem layout of Windows Vista and
later, did you?

Hardlinks are extensively used in WinSxS to link the DLLs and executables to
places where they used to live. Symlinks are used for many of the legacy
directory names that some applications have hardcoded, e.g. C:\Documents and
Settings links to C:\Users.

~~~
Dylan16807
But the user has no access to file symlinks without escalating to admin every
time they want to make one.

~~~
tanzam75
> _But the user has no access to file symlinks without escalating to admin
> every time they want to make one._

By default.

This is a security restriction, like UAC. And so you can turn it off, just
like you can turn off UAC.

~~~
Dylan16807
And requiring that makes it useless for most purposes.

------
GoodIntentions
perhaps someone has posted it, but I don't see it here:

[https://en.wikipedia.org/wiki/Subst](https://en.wikipedia.org/wiki/Subst)

Gotta really stupid-long base path? alias it.

------
jongalloway2
This .NET library from the .NET BCL team helps a little:
[http://bcl.codeplex.com/wikipage?title=Long%20Path&referring...](http://bcl.codeplex.com/wikipage?title=Long%20Path&referringTitle=Home)

------
wmt
Fixing it on visual studio would still leave it unfixed the Windows API and
for almost all other software, e.g. you can't open files with path > maxpath
from windows explorer. Visual studio support would not help much.

------
moca
If Windows has good enough support for symbolic link, this wouldn't even be a
problem in practice. There always is some way to solve the problem other than
declining it.

------
blt
Another fun one: the Line Number variable in Visual Studio's debugger is
16-bit. In huge generated files, you can't step through code beyond line
65535.

~~~
me_again
This is not actually true. I just tried it.

------
golergka
Oh my god. I don't use windows anymore, but I remember this limit of 260
characters from DOS 6.0. I just assumed that they already fixed it long ago.

------
tempeh
And this, children, is why we take proper abstraction very seriously.

------
qwerta
There is old joke which is now actually true. The best Win32 implementation is
Wine on Linux :-)

~~~
qwerta
Why downwote? Oh I see; fixed version: Wine on Mac

