The maximum length for a path (file name and its directory route) – also known as MAX_PATH – has been defined by 260 characters. But with the latest Windows 10 Insider preview, Microsoft is giving users the ability to increase the limit.
The recent most Windows 10 preview is enabling users to change the 260 characters limit. As mentioned in the description, “Enabling NTFS long paths will allow manifested win32 applications and Windows Store applications to access paths beyond the normal 260 char limit per node.”
Did anyone ever run into this limit? It seems like something that would really be bothersome on servers.
If you are using node with Windows installing new modules using npm 2 you could run into this limit.
https://github.com/npm/npm/issues/3697
When using TFS (Team Foundation Server basically Microsoft’s version of Bitbucket/Jira) If you set you workspace on anywhere other than C:\ and your co-workers didn’t think through their usage of source control you could run into this.
https://social.msdn.microsoft.com/Forums/vstudio/en-US/01ab51c6-75e8…
This would never happen for the average joe.
Edited 2016-05-30 21:20 UTC
I ran into this thing quite a lot. Developing on TFS, with WWF (Windows Workflow Foundation). And on your dev machine you could move your workspace to C:\… on the build server though. SUPER ANNOYING. And very hard to fix. Needed all kinds of tricks in the code to make the length of the filenames (that were autogenerated) a couple of characters shorter.
Glad it’s finally gone.
260 is not enough for everyone!
Luckily we are using TFS with Git rather than old school TFS which was sourcesafe on steroids.
I always had the problem where someone would reference a dll about 6 levels down from where the csproj lived. I wanted to start using less and gulp to get a decent front end workflow. I can’t move the workspace without making a NTFS juncture on my machine, when when another developer gets hold of the code the front-end build will fail. You just can’t win.
“… You just can’t WIN.”
Seen so many years endings > just can’t ‘WIN’, haven’t noted.
😉
NTFS has a limit on the entire path of 32,767 characters. The Win32 API imposed a limit of 260 characters, known as MAX_PATH. Previously, to exceed MAX_PATH, an application needed to bypass Win32 evaluation using \\?\ prefixes; now, if the application is manifested and the option is enabled, the prefix is not required.
What this means is that there is no automatic support for existing applications either way. Previously the app needed to change code to add the prefix; now the app needs to change to declare support in its manifest. This makes it easier for app developers, but it does not suddenly light up extended path support to existing applications, including most of Windows.
To make this work end to end, applications cannot depend on fixed size stack-based buffers when dealing with paths. This can be a big change to make, depending on the codebase.
Very much agreed, though hard to change for older software code bases. This specific value has so much history behind it and people hard coding around it that it will probably never really change from 260.
Most likely either people have already converted the relevant apps from the ASCIIZ Win32 API to Unicode Win32 API to get around this limitation already or the code base will never be updated to support >260 bytes in a path.
Oh, and if they think about changing that Unicode Win32 API limit of 32k, well…there are probably a sizable chunk of applications out there that are hard coded without any constant variables (because non-exist from Microsoft) too.
And yes, I’ve done development and testing for applications that have hit or needed to be validated for these limits.
“Did anyone ever run into this limit?”
several times.
scientific papers can have extremly long names.
one i just happen to have here on my laptop is
D:\Bücher\_Papers\A new approach to generating arc length parameterized NURBS tool paths for efficient three-axis machining of smooth, accurate sculptured surfaces.pdf
it already clocks in at 167 characters
one extreme case i remember was a chemical paper where the title alone cracked the 200 character mark
it had a list of elements in the title…
Edited 2016-05-30 21:37 UTC
smashIt,
For me, I don’t think the 260 char limit is too bad for naming purposes. To be honest I’d probably have a bigger gripe that file names are that big
The scenario where I’ve found the path limit to be frustrating is the couple times I’ve been prevented from copying an existing filesystem into a subdirectory on a different disk.
Before having a NAS solution, this is what I would do every time I’d upgrade my desktop hard disk.
At the other end as well, I ran into that issue constantly during data gathering/simulation runs for some papers.
Leave it to microsoft to soil a blank slate.
“Did anyone ever run into this limit?”
Daily, humans tend to love a good description, for the archive, and the archive will be unpacked in the folder, for the day, for the project phase, for the speciality… you get the point.
So, on a daily basis I answer some questions with “maybe it did not work because the path is too long?!”.
Also this tends to break some havoc when working with remote sites that run sensible OSes that don’t have such a limit, servers/NAS/etc, and users end up with less than they wanted transferred.
/LE: For Windows 10 only? Muahahahahahhahahahahahahahaaaaa
Edited 2016-05-30 22:29 UTC
Beyond Medium Term this is very good news!
If understanding MS calendar they express duty to take compatibly win10>Win8. Win7 on security maintaining only. [They 7 should, or some third party will, consequent mess].
[Upgraded an old AMD C-50 2Gb! little clam thing win7>win10 and it feels a lot more snappier]
Hell yeah. There’s still stuff I can’t download from Newsleecher because the nimrod who uploaded the files named them 250+ characters long
I have certainly run into that limit especially with people that keep their documents well organized into directories and descriptive document tittles.
Backups on those directories become a pain in the ass and the same with restoring content.
I am extremely happy that they’re doing this, and hopefully backup software takes advantage of this (third party that is).
It would also create lots of fun when migrating file servers to a new server. Financial departments and lawyers seemed to be the most common offenders for exceeding path limits.
As a Java developer on Windows (I know, I know, it’s not like the company platform is mine to choose…), I regularly hit the wall. Even just copying a project directory becomes impossible sometimes, and I have to be careful to have short package names and shallow package hierarchies in order to leave enough space for the actual class names. This is great news to me. 🙂
I’ve met this limitation both at home(renaming a file to a meaningful name in a deeply-nested directory) and professionally (checking out source code to a deeply nested directory).
That was really annoying. Sure you could work around this but that was annoying. The worst part of this fix, is that as there is no Vista, 7 and Windows Server backport, is that it will take years for the industry to remove workarounds.
Oh yes! I was once tasked with setting up a Jenkins build node running Windows 7. Its job was to produce Android builds and I would have much preferred Linux. My manager wanted Windows though since that was what the developers were using. It wasn’t completely unjustified: builds would usually fail on Linux due to small errors such as wrong capitalisation in C includes.
The project was quite large and would often brush up against the Win32 character limit. Developers were urged to place the project directly under C:\. The problem with Jenkins is that its directory structure would easily add 50 characters or more to the file paths, e.g. C:\jenkins\jobs\my-project.android.release\workspace\.
Shortening the names of the build jobs and moving some things around in the code repository were not enough. I ended up creating a new folder under C:\ containing links to the separate workspaces. The links were named using the first few characters of the checksum of the name of the build job. However, I needed a type of link that would not be resolved by either Windows or Cygwin commands. To this day I’m not fully sure what a “junction” does, but at least my bodge worked. That was far from the only problem I had to solve though.
(I feel the need to add that I’m mainly an OS X and Linux person. Windows is still quite alien to me.)
One area where people recently started running into this problem (and which possibly prompted Microsoft to make this change) is the Windows Subsystem for Linux (WSL).
You sure? Because this is a Win32 limit, not a kernel limit or an NTFS limit (Which supports 32k-long wide-character path lengths). Specifically, there is a MAX_PATH constant that places the 260-char limit at build time, and there are already ways to work around it (using UNC paths, i.e. those that start with \\?\ )
Win32 software that supports UNC paths still has the 260 char limit when using traditional paths starting with the drive letter and colon.
Since it isn’t Win32, WSL shouldn’t be affected.
I find this interesting. I never knew there was any limit other than the 255 UTF-16 code unit limit per file-name (which is pretty similar to the 255 byte limit for file-names on most other modern filesystems).
we have lawyers at our company, and they love to name a file with the content of the first paragraph of any document to make it “easy to search”, so yeah, IT is facing daily this kind of situation…
Windows has two annoying limits that most UNIX systems do not have. Its maximum command length is pretty short and the maximum path is very short. I like to keep my external deps in the same structure as they would on a *NIX system and when installing boost the doc folder often exceeds this path length and when I do not use private includes in CMAKE the -I flags can often add up and exceed the maximum command length which leads to some fun failures.
Brother Lawyer. Used to write full SYNOPSIS of their Legalese, as File Names! Why? Why MS Word allowed this? Only God and some morally damaged developers at Microsoft knows. Broke all kind of things.
Most important: File Transfer or Backup after those unrecoverable collapses requiring LOW LEVEL formating where a one by one painful experience for every file going over the limit of the open NTFS specification.
Those millipede names couldn’t be trimmed to the open specification max length because they contained strategic information to my brother’ work.
……..
Not recommending early activation of this feature on users’ rigs until sure all relevant tools are compatible with this feature.
Lawyers have a tendency to ‘break’ a lots of things. Not bad intention [as far as my brother goes].
Something like a transform of:
“Everything not forbidden is allowed”
toward:
“Everything not impossible is [unworryingly] possible”.
Lawyer specific OSs should be written
Edit: Oops. Malxau already said all of this above.
To be clear, upping the MAX_PATH won’t magically give your apps longer path support, and it also (shouldn’t) break any existing apps.
MAX_PATH was a constant, defined at build. Software built using this constant to define enough space in memory for a path would overflow if Windows APIs started returning longer paths, so old apps will still have the 260 char limit. New apps have to declare in their application manifest that they support longer paths. Without that declaration, Windows will continue to only offer up paths with a max of 260 chars.
The reason this limit exists, though, is that it is a holdover from DOS and the early days of Win32. The reason why it has never changed is compatibility – Microsoft doesn’t change APIs. That’s why they created new APIs for longer UNC paths.
Edited 2016-05-31 17:59 UTC
I reach that limit almost every day I have to develop on Windows. Fortunatelly, that doesn’t happen more than once every a few years. It’s hard to be a serious developer if you use an OS that seems to hate users (among them, developers). Linux FTW
I am yet to experience a developer friendly environment as Windows, probably followed by Mac OS X.
For me a suitable developer experience is based in IDEs, REPLs, graphical debuggers and UI designers and saner languages as straight C for system software.
A Xerox PARC experience, not an AT&T one.
Not all developers live on the command line, or enjoy having to use it for mundane tasks.
Back when I used windows for development, this was pretty common. I was pleased when I read it wasn’t NTFS but windows api that was the problem, I thought it would be fixed in windows 2k. Then XP, then longhorn…
In my working place, some people uses Linux, others Windows (mostly bosses). So, this became a real issue.
Some Linux developers would commit files with long paths (due to our internal folders organization and the fact that Java source-codes consumes a lot of path with /br/com/etc/etc/etc/SomeLongClassName.java)
Then a boss would call me because Windows machines refuses to pull the files…
This was a constant issue when I was using Symantec Ghost. While the issue could have been solved by canonizing paths (sometimes, anyway), canonizing on Windows is nowhere near as simple as on Unix.
I’m glad that at least some of Microsoft’s FS is finally boldly stepping into the 21st century.
I’ve done file server/client development before and had to validate our code honored this limits. As I’ve said elsewhere, there’s going to be a lot of unintended consequences, and I don’t think that all the ASCIIZ Win32 API using software will ever truly be upgraded given this change. That said…
There are several work arounds:
[1] Upgrade to using the Unicode WIn32 APIs and have a 32k wchar_t limit.
[2] Mount a directory deeper in the path to a directory higher in the path to remove some of the path (e.g a Linux Symlink).
Windows had had the ability to do #2 since sometime with Win2k, but the tools were not really easy to use until WinXP and even later with Windows Vista (with mklink).
Forgot one of the work arounds:
[3] using the DOS 8.3 names instead of the LFN names (e.g C:\SomeFileNameThatsLong -> C:\SomeFil~1)
Well, I would argue that using wchars is not really an upgrade.
True…but it is a work around for this issue, and a well documented and recommended one at that.
While Windows offers ASCIIZ and WideString (Unicode 16LE) APIs, MS really recommends and pushes using the Wide-String APIs. For example, if you use MFC and CStrings and take the defaults in Visual Studio you will end up using CStringW and all the Wide-String APIs.
And I would be extremely surprised if they did not code .Net, C#, etc using the CStringW and Wide-String Win32 APIs in the back-end so that .NET users would not have to care – they would automatically get Unicode.
I had run into this issue so many times, when working with .net based projects because of the namespaces.
I have had it happen many times when attempting to mirror data from Linux to Windows boxes. It apparently happens often enough there is a third party workaround tool for it – the long path tool: http://longpathtool.com (version 5.x at the moment)
Edited 2016-06-01 12:35 UTC
I have run into this problem several different times. Copying directories from one machine to another where you are placing the directory into a deeper subdirectory. You don’t always get to choose your own filenames and some of them can be very long and/or have deeply nested subdirectories.
A few years ago when I attended a seminar by a developer on Bazaar (the VCS software), I mentioned that I’d been using Mercurial to manage my project and he said that Mercurial’s practice of converting capital letters to an underscore followed by the lowercase could make it more likely to run into that limit. I mostly use Linux and OS X and don’t give my application files long or overly descriptive names, but if you do it might be a disadvantage.