Linked by Thom Holwerda on Mon 30th May 2016 21:14 UTC, submitted by Răzvan T. Coloja
Windows

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.

Order by: Score:
Ran into this regularly
by lucas_maximus on Mon 30th May 2016 21:18 UTC
lucas_maximus
Member since:
2009-08-18

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

Reply Score: 4

RE: Ran into this regularly
by elangelo on Tue 31st May 2016 05:51 UTC in reply to "Ran into this regularly"
elangelo Member since:
2012-09-19

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!

Reply Score: 2

RE[2]: Ran into this regularly
by lucas_maximus on Tue 31st May 2016 09:58 UTC in reply to "RE: Ran into this regularly"
lucas_maximus Member since:
2009-08-18

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.

Reply Score: 2

RE[3]: Ran into this regularly
by dionicio on Tue 31st May 2016 17:24 UTC in reply to "RE[2]: Ran into this regularly"
dionicio Member since:
2006-07-12

"... You just can't WIN."

Seen so many years endings > just can't 'WIN', haven't noted.

;)

Reply Score: 2

Don't get too carried away...
by malxau on Mon 30th May 2016 21:21 UTC
malxau
Member since:
2005-12-04

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.

Reply Score: 10

TemporalBeing Member since:
2007-08-22

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.


So the Win32 API is an oddball here.

The ASCIIZ Win32 APIs (e.g CreateFileA()) would limit the length of the entire path to 260 characters (well, really 255 once you counted in <drive>:// since <drive> could be 2 characters).

However, the Unicode Window APIs (e.g CreateFileW()) would limit it to 32k wchar_ts (16-bit unicode characters) in its entirety - including the \\?\ prefix which would denote it as a Unicode path.

That has been the case for a very long time.

How, MAX_PATH has traditionally been just a constant at build time. So reality is that this won't affect most software until a new version is released and is recompiled with the new MAX_PATH value, and assuming that they use it properly. As with most things Windows-oriented this is going to lead to a lot of buffer-overflow issues as all of the software looking at MAX_PATH typically has static, compile-time buffers on the stack built around using MAX_PATH and my guess is that the vast majority of them do not use the MAX_PATH preprocessor define to make the buffer size or even to clear it, and most probably do not use a CString (CStringA) when working with it either since it has for the entire history of the Windows OS (long before Win32 API even) been limited to 260 characters, and the fix was to convert to the Unicode APIs and using CStringW.

So is this change a good thing? Not really.

Yes, it's desirable but its going to break so much software out there that it really isn't a good thing. There's going to be so many unintended consequences that it's going to be a nightmare for developers.

Though this will certainly be a good example for why developers should actually use the pre-defined constants instead of making their own variables or hard coding values, which is often the case around MAX_PATH; but that wasn't helped by the fact that Microsoft made it hard to the MAX_PATH constant without importing a whole lot of other crap, at least until recent header file changes.

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.


Well that should help mitigate issues with older software, but I expect that at lot of that software will still ship with major buffer overflow bugs because they'll fix it in obvious places or just re-compile with the new value and then miss the fact that there were a few hundred non-obvious places. Still, better than nothing.

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.

Reply Score: 3

Comment by smashIt
by smashIt on Mon 30th May 2016 21:32 UTC
smashIt
Member since:
2005-07-06

"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

Reply Score: 6

RE: Comment by smashIt
by Alfman on Mon 30th May 2016 22:00 UTC in reply to "Comment by smashIt"
Alfman Member since:
2011-01-28

smashIt,

scientific papers can have extremly long names.


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.

Reply Score: 2

RE: Comment by smashIt
by tylerdurden on Tue 31st May 2016 08:14 UTC in reply to "Comment by smashIt"
tylerdurden Member since:
2009-03-17

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.

Reply Score: 2

Comment by Licaon_Kter
by Licaon_Kter on Mon 30th May 2016 22:28 UTC
Licaon_Kter
Member since:
2010-03-19

"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

Reply Score: 2

RE: Comment by Licaon_Kter
by dionicio on Tue 31st May 2016 16:54 UTC in reply to "Comment by Licaon_Kter"
dionicio Member since:
2006-07-12

Beyond Medium Term this is very good news!

Reply Score: 2

RE: Comment by Licaon_Kter
by dionicio on Tue 31st May 2016 17:09 UTC in reply to "Comment by Licaon_Kter"
dionicio Member since:
2006-07-12

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] ;)

Reply Score: 2

Newsleecher
by WorknMan on Mon 30th May 2016 23:06 UTC
WorknMan
Member since:
2005-11-13

Did anyone ever run into this limit?


Hell yeah. There's still stuff I can't download from Newsleecher because the nimrod who uploaded the files named them 250+ characters long ;)

Reply Score: 2

Yes I have run into the limit
by Poseidon on Tue 31st May 2016 00:48 UTC
Poseidon
Member since:
2009-10-31

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).

Reply Score: 1

Comment by Undomiel
by Undomiel on Tue 31st May 2016 01:13 UTC
Undomiel
Member since:
2007-11-23

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.

Reply Score: 1

Yayyy
by timber on Tue 31st May 2016 04:35 UTC
timber
Member since:
2007-12-30

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. :-)

Reply Score: 3

Sure did
by loic on Tue 31st May 2016 08:34 UTC
loic
Member since:
2012-09-23

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.

Reply Score: 2

Jenkins woes
by TasnuArakun on Tue 31st May 2016 11:16 UTC
TasnuArakun
Member since:
2009-05-24

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.)

Reply Score: 1

Linux subsystem interoperability
by chithanh on Tue 31st May 2016 12:02 UTC
chithanh
Member since:
2006-06-18

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).

Reply Score: 2

Drumhellar Member since:
2005-07-12

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.

Reply Score: 3

Interesting...
by ahferroin7 on Tue 31st May 2016 12:33 UTC
ahferroin7
Member since:
2015-10-30

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).

Reply Score: 1

lawyers everywere
by Risthel on Tue 31st May 2016 14:19 UTC
Risthel
Member since:
2010-12-22

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...

Reply Score: 1

Often Run in to this
by IgnitusBoyone on Tue 31st May 2016 14:37 UTC
IgnitusBoyone
Member since:
2007-02-07

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.

Reply Score: 2

Comment by dionicio
by dionicio on Tue 31st May 2016 16:11 UTC
dionicio
Member since:
2006-07-12

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.

Reply Score: 4

RE: Comment by dionicio
by dionicio on Tue 31st May 2016 16:20 UTC in reply to "Comment by dionicio"
dionicio Member since:
2006-07-12

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 ;)

Reply Score: 2

Comment by Drumhellar
by Drumhellar on Tue 31st May 2016 17:51 UTC
Drumhellar
Member since:
2005-07-12

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

Reply Score: 2

yes, I reach it
by eazel7 on Tue 31st May 2016 18:25 UTC
eazel7
Member since:
2007-09-09

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

Reply Score: 2

RE: yes, I reach it
by moondevil on Wed 1st Jun 2016 10:57 UTC in reply to "yes, I reach it"
moondevil Member since:
2005-07-08

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.

Reply Score: 2

Yeah, years ago
by Bill Shooter of Bul on Tue 31st May 2016 18:35 UTC
Bill Shooter of Bul
Member since:
2006-07-14

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...

Reply Score: 2

This was a real problem
by stanbr on Tue 31st May 2016 19:03 UTC
stanbr
Member since:
2009-05-22

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...

Reply Score: 1

YES!
by FlyingJester on Tue 31st May 2016 19:51 UTC
FlyingJester
Member since:
2016-05-11

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.

Reply Score: 1

Favorite work arounds...
by TemporalBeing on Tue 31st May 2016 19:55 UTC
TemporalBeing
Member since:
2007-08-22

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).

Reply Score: 2

RE: Favorite work arounds...
by TemporalBeing on Tue 31st May 2016 21:17 UTC in reply to "Favorite work arounds..."
TemporalBeing Member since:
2007-08-22

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)

Reply Score: 2

RE: Favorite work arounds...
by FlyingJester on Tue 31st May 2016 22:30 UTC in reply to "Favorite work arounds..."
FlyingJester Member since:
2016-05-11

Well, I would argue that using wchars is not really an upgrade.

Reply Score: 1

TemporalBeing Member since:
2007-08-22

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.

Reply Score: 2

About time
by MeTitus on Wed 1st Jun 2016 09:10 UTC
MeTitus
Member since:
2011-08-19

I had run into this issue so many times, when working with .net based projects because of the namespaces.

Reply Score: 1

Long Path Tool
by jeffclayton on Wed 1st Jun 2016 12:19 UTC
jeffclayton
Member since:
2016-06-01

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

Reply Score: 1

It is an issue
by abraxas on Wed 1st Jun 2016 23:04 UTC
abraxas
Member since:
2005-07-07

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.

Reply Score: 2

Mercurial
by IndigoJo on Thu 2nd Jun 2016 20:02 UTC
IndigoJo
Member since:
2005-07-06

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.

Reply Score: 1