9 ms·
Fix 260 character file name length limitation: Declined
- Already__Taken 13y agoI 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.
- unsignedint 13y agoI think that's file name limitation. I think NTFS allows 32767 for full path...
- cryptos 13y agoYes, NTFS would support much longer paths than 260 characters.
- masklinn 13y ago> I always thought this limitation came from NTFS, or at least a previous version of. NTFS allows paths up to 32767 UTF-16 code units (after expansions) with each path component (between `\` separators) up to 255 code units, and this is available through UNC paths. MAX_PATH is a Windows API limitation, and thus a limitation implicitly inherited by many windows-based software which use MAX_PATH as storage limits and buffer sizes. Changing filesystem will not fix WinAPI issues.
- ygra 13y agoI wonder whether there was a right answer at the time MAX_PATH was conceived. It certainly is nice to have a hard upper bound for buffer sizes path API functions will fill and 32k would be a bit large to use by default.
- earlz 13y agoNTFS 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 13y agoYou 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 13y agoBut the user has no access to file symlinks without escalating to admin every time they want to make one.
- tanzam75 13y ago> 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 13y agoAnd requiring that makes it useless for most purposes.
- marshray 13y agoThe 'shortcut' thing came from Win95, which ran on the VFAT filesystem.
- rogerbinns 13y agoIt comes from the operating system pathname parsing code. That is why you can do things with a deeper current working directory. There is an alternate parser, but the name has to start with \\? and then it takes up to 32kb of text.
- jonchang 13y agohttp://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx#maxpath http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.... http://stackoverflow.com/questions/1880321/why-does-the-260-character-path-length-limit-exist-in-windows/ http://stackoverflow.com/questions/1880321/why-does-the-260-... http://www.codinghorror.com/blog/2006/11/filesystem-paths-how-long-is-too-long.html http://www.codinghorror.com/blog/2006/11/filesystem-paths-ho... Summary: The assumption has been baked in forever and changing it is Non-Trivial. Workarounds exist though! (Kind of.)
- deleted 13y ago[deleted]
- EdwardDiego 13y agoYep, our Maven project routinely fails to build on Windows as there are some paths which are just too long.
- kbar13 13y agooh no, how will my Enterprise Java Enterprise Application work on our Windows Enterprise Production Enterprise Datacenter Edition?
- svachalek 13y agoThe "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.
- malaporte 13y agoErrr, 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?
- SolarNet 13y agoThird parties in their own company...
- kevin_rubyhouse 13y agoI 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 13y agoPeople 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.
- throwaway9101 13y ago> 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
- pdw 13y agoI've often seen normal people come up with deeply nested directory structures with long descriptive names and they get bitten hard by the 260 character limit. For example names like this are very common in my experience: C:\Documents and Settings\Joe Random User\My Documents\Some Cloud Software\Company\Projects\2013\156 Big Customer Inc\Locations\Someville Foostreet\Problem reports\2013-10-07 product not working\images\video of product not doing what it's supposed to do.avi Also: find . | python -c 'import sys; print max(sys.stdin.readlines(), key=len)'
- Eiwatah4 13y ago$ find / -mindepth 10 | wc -L 273 I seem to have some slightly longer file paths on my home computer. Do I need that? Probably not. I could move those files somewhere else. But should I really have to worry about such things?
- VMG 13y agoreached 248 here when run against my home dir. Interestingly the winner is the path to a transitive npm dependency five(!) levels down the dependency tree. The command I used: find -mindepth 10 | awk '{ print length(), $0 | "sort -n" }' | tail
- oakwhiz 13y agoCertain SBT plugins and build settings can generate really deep nested paths under the "target" folder of a project. I think the point of this is to enforce file immutability during the build process - whenever a file is modified by a build stage, a new file is created instead. I could be completely misunderstanding this though since SBT is fairly complex.
- PaulHoule 13y agoUnfortunately 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 13y agoIt 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 13y ago> 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...
- adandy 13y agoAm 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 13y agoCheck 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.
- maddddddddddddd 13y agoM$ sucks... M$ tools suck... i get it.
- chao- 13y agoI 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.
- cryptos 13y agoSame here, but with Windows' own backup tool.
- fleitz 13y agoThis is only related to the path, if you recursively delete from the top level then it doesn't work, but if you switch CWD to a lower level directory then you can delete the files. eg. rm -rf C:/REALLY/LONG/PATH/ doesn't work but cd REALLY cd LONG rm -rf PATH cd .. rm -rf LONG cd .. rm -rf REALLY works (windows equivalents of course) In past projects I've ended up rewriting most of of System.IO that dealt with paths to fix this issue. Basically all you have to do is prefix your path with \\?\ and voila it works. (Except in .NET which detects you're doing this and stops it)
- VLM 13y agoThis is going to look linux because I don't use windows, but you can automate this by writing two scripts and putting both in your path #!/bin/bash while [ 1 ] do cd .svn done The other looks like this #!/bin/bash while [ 1 ] do cd .. rm -Rf * done Now just run the first until it can't cd any deeper, and then run the second to clean your hard drive very throughly. (note I know darn well what script #2 does ... this would probably make a good debugging question for a sysadmin interview... in case you don't get it, for gods sake don't run script #2 unchanged)
- tempeh 13y agoAnd this, children, is why we take proper abstraction very seriously.
- amadvance 13y agoDear 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.
- qwerta 13y agoThere is old joke which is now actually true. The best Win32 implementation is Wine on Linux :-)
- qwerta 13y agoWhy downwote? Oh I see; fixed version: Wine on Mac
- w-m 13y agoLooking 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
- ianstallings 13y agoWhat'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.
- jongalloway2 13y agoThis .NET library from the .NET BCL team helps a little: http://bcl.codeplex.com/wikipage?title=Long%20Path&referringTitle=Home http://bcl.codeplex.com/wikipage?title=Long%20Path&referring...
- zdrummond 13y agoThis 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/aa365247(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa36... [2] I don't heavily use Windows anymore, but when I tested < Windows 8 machines with > MAX_PATH, Explorer did not work.
- mappu 13y agoMAX_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.
- jussij 13y agoNot only is it never going to happen, they would be mad to try. Even, if they did make the change and somehow managed to re-test and fix all their software, they would still have created the potential of breaking every piece of Windows software in existence. Making the change has to potential to cause untold chaos, the likes never before seen in the software industry. It would make Y2K look like a paper cut.
- XorNot 13y agoOk 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 13y agoConsider 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.
- GoodIntentions 13y agoperhaps 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.
- blt 13y agoAnother 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 13y agoThis is not actually true. I just tried it.
- wmt 13y agoFixing 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 13y agoIf 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.
- golergka 13y agoOh 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.