Slashdot Mirror

There's nothing simple about fucking around in the registry. Why can't Microsoft just do things correctly the first time?

https://technet.microsoft.com/...

Or just use the approved way. This seems like an 'enterprisy' feature. Something you would set in active directory.

NTFS allows 65535 unicode sized char entries per level of directory. With I think up to 255 levels deep (have to look it up). Which I believe is an arbitrary number and easily ignored.

The 260 char limit is a leftover from DOS and just about every example on MSDN.

Why not just turn this on by default? If this breaks some kind of DOS convention, then it's likely only relevant to enterprise users running some legacy crap, and assuming they run Windows 10 at all, I highly doubt they're going to upgrade to this build any time soon anyways.

There's nothing simple about fucking around in the registry.

Really? If you have problem with the registry how do you cope with the file system with all its folders? Or even the nested comments of Slashdot? I think that you are making this out to be a much bigger problem than it really is.

The link you posted has absolutely nothing to do with the topic, troll.

It might cause program crashes if the programs use PATH_MAX.

You're a fucking idiot. The registry is not meant to be played with, it's a good way to fuck up the computer.

Yes, we can all go in and make changes, but it used to be done sparingly, now it's the suggested method for all fixes.

> Really? If you have problem with the registry how do you cope with the file system with all its folders?

I don't give them names like {48981759-12F2-42A6-A048-028B3973495F}, for starters.

The registry is actually fairly basic, it's just also huge and pretty poorly documented. Yes, you can screw up your computer pretty good if you do the wrong thing, just like messing with stuff in the system directory, or in ancient history, in the dos directory, but that's why you should be careful, have a backup, and don't play around or randomly experiment.
Anyone who feels comfortable changing a simple registry entry is almost guaranteed to be able to do this without issue. Anyone who isn't probably doesn't even know what this change even does in the first place.

There's undoubtedly a lot of code out there that has:

#define MAX_PATH 260
wchar buffer[MAX_PATH];

And by "legacy crap", you presumably mean "every version of Windows, ever". Because this has been the rule for Windows unless you did some funky tricks with your paths ("\\?\D:\very long path"), which gives you paths up to 32K in length.

It's about time they did away with that limit. It's sort of rare, but you can occasionally run into path limits, especially with deeply nested computer-generated filenames, etc.

Because Windows 10 is not systemd.

Unconverted human detected!!! http://movieboozer.com/wp-cont...

Is this sub-thread for real?

This will resolve a lot of pain in the npm ecosystem.

DOS conventions can be broken, but what about earlier Windows versions accessing the drive via network share? Could create serious problems there.

It's worse than that. The Windows SDK still uses that convention for much of the Win32 API.

Yes, this change will create a buffer overflow issue for just about every Win32 program. Perhaps Microsoft has just decided that they want to kill every program that predates Win10 and try to force recompilation to the new binary format which coinsidentially requires installation them from Microsoft store..

Network shares always had that problem - though I'm not sure if it was the path name length or invalid characters, but some 16 years ago we had to use Samba to remove a directory tree from a Windows server, that Win32 could not handle.

The only person who said "fag," here was you. Are you writing about your dreams again? Just kidding, I know you are.

If you have problem with the registry how do you cope with the file system with all its folders?

The problem with the registry isn't that it is hard to navigate a hierarchical database, but the way it is being used, apparently to deliberately obfuscate the way applications are configured. As a result, it has become an obscenely hideous structure - compare this to the traditional UNIX style of configuration, in simple text files requiring just a text editor and a manual telling you how to do (another thing that is very often absent in Windows). And even if the manual doesn't exist, you can often make reasonable guesses, because it is in clear text. For me it is this, more than anything else, that makes Windows so profoundly unattractive - I cannot think of any good reason not to follow the UNIX method; I can think of bad reasons, like wanting to make the system less easy for the user to control, but no good ones.

If you view the registry as a separate "filesystem" just for configuration files, isn't it similar to the unix method?

There's nothing simple about fucking around in the registry.

Really? If you have problem with the registry how do you cope with the file system with all its folders? Or even the nested comments of Slashdot? I think that you are making this out to be a much bigger problem than it really is.

Yes, of course it's easy! That's why I added a desktop shortcut for every user that takes them right into the registry.

After all, it's as easy to use as Windows Explorer, and what could possibly go wrong....

From TFA:

As you can see, Microsoft is making this change not only to Win32 software but also to Windows Store applications, as they’re playing an essential role for the future of Windows. Application manifests, which are mostly resources included in every executable file for compatibility reasons, will require apps to add a mention of this new policy, thus making sure that they support a path longer than 260 characters.
This means that unless it’s specified, the change won’t be supported, so apps will need to be updated by developers to benefit from this new behavior.

So, no, this shouldn't cause an issue unless a developer is stupid enough to put the required manifest information in without actually ensuring the code can handle the longer paths/filenames.

No. RTFA

The registry is supposed to enforce a common method of storing settings across all Windows apps. Of course, that laudable idea has then been tested by twenty odd years of pretty much everyone writing software for Windows in their own special way, and maybe about 10% bothering to follow Microsoft's standards. And of course, even different departments of Microsoft have their own ideas of how things should be done, so Office does things differently to SQL Server and so on.

tl/dr the idea behind the registry was fine, but it's been abused for years.

Interesting, I can now create buffer overflow attacks by making long file names. Cool . . .

It's about time they did away with that limit. It's sort of rare, but you can occasionally run into path limits, especially with deeply nested computer-generated filenames, etc.

For some reason I keep on running into it with Workplace Health and Safety people who like to set policies of incredibly long directory names and filenames with punctuation in them - plus very deep nesting while repeating part of the name of the directory above. Having a *nix fileserver I can rename things for them when they fuck up and a copy will not work but they keep on doing it despite years of advice not to. It snowballs as the copy stuff from the fairly shallow nesting of their laptops or whatever into deep in the final repository and they find that yet again the path is way too long.
As ridiculous as this sort of thing but more tedious:
Minutes of Meeting on the topic of some_long_topic_here, Friday September 23rd\Joe Bloggs & Fred Nurk on the topic of some_long_topic_here\MSDS submitted by Joe Bloggs & Fred Nurk on the topic of some_long_topic_here Friday September 23rd\MSDS-0000094 Soap on a rope, washing for the use of.PDF

That sort of thing which just looks idiotic given the constraints of the system.

https://technet.microsoft.com/...

Or just use the approved way.

There might not be a ADMX for it yet. There are a couple of GPO settings there are no proper templates for. Annoying as hell.

For 99% of applications it's pretty simple actually. One HKLM\Software (or 64 bit equiv) key, and one HKCU\Software key per user. As long as you are not dealing with something that includes drivers or something crazy like that.

Because then Microsoft wouldn't be honoring the tradition of having every setting in Windows backwards of the way you actually want it by default.

*nix-style config files suck ass. There are about eleventy-billion formats, all inconsistent with each other. Most of them allow, for example, the "#" character to mean a comment. Others, however, use C- and C++-style comments, both block and line. Still other formats mix and match those. And then there are the ones that, for some inexplicable reason use some completely other comment marker. And that's all just for comments! That doesn't even touch the insanity of various single-line-only, block-delimited, and/or pseudo XML/INI/JSON/whatever-else formats that don't quite match any real standard.

No, I'll take the registry over that. And preferable even to that, a well-documented, well-integrated text-based config file format that has ONE, hard-and-fast format. Oh, wait... Microsoft did that too when they learned their lesson from the registry and made .Net config files. The registry has been officially discouraged for a solid 10 years now, and they've threatened to deprecate it with every OS and dev tools update for the last 15 years, though without following through.

Now march that high horse right back out the door.

So, no, this shouldn't cause an issue unless a developer is stupid enough to put the required manifest information in without actually ensuring the code can handle the longer paths/filenames.

Even if Windows hides paths longer than 260 from legacy apps... What, exactly, will Windows return for a call to GetCurrentDirectory(), when a legacy app runs from a path longer than that? What happens when the user tries to explicitly load or save a file from such a path (as in, paste the too-long path directly into the file dialog, which then tries to stuff it into a variable defined as 260 characters long)?

I can't see any way for this not to break a ton of legacy apps, in potentially dangerous ways, regardless of whether MS checks their manifest.

Someone would have had to have made the choice to have such a long path. I'm pretty sure I don't get anywhere near it. Even one of the longer paths inside my %LOCALAPPDATA% is still under 100 characters. Sure, it's something anyone enabling this will have to be aware of.

There's undoubtedly a lot of code out there that has:

#define MAX_PATH 260 wchar buffer[MAX_PATH];

Undoubtably because that's defined as such in the Windows.h header file for both VS and the GCC off-shoots. Microsoft has known for years that this was a problem, but they also acknowledged the pain that a change like this would cause for thousands of developers and even more so for the poor bastards like me who have to support end of life software where we can't simply make a change and then recompile the source code to fix this problem. I kind of wanted them to leave this one alone, but I guess they are dead-set on resolving all of the little nagging criticisms they hear from your *nix-tards about how the dominant product in the PC market is "inferior". Congratulations internet, you've made a huge step in progress for the world and have simultaneously accomplished nothing but causing pain and grief.

"Really? If you have a problem with bash, how do you cope with Word with all its keystrokes? Or even the comments box on Slashdot? I think that you are making this out to be a much bigger problem than it really is."

(The problem isn't with the RegEdit UI, it's the fact a setting is buried somewhere in massive block of tens of thousands (maybe millions?) of entries, only barely made slightly easier to navigate through a hierarchy that only sometimes makes sense.)

So to avoid inconsistent methods to place comments, you prefer a format that does not allow comments AT ALL?
Can get that by just not using comments in your UNIX config files.
Sure, not your main point... But if you go and pick a single format like .Net config files (which basically nobody uses anyway though) then of course that looks all consistent. Of course just wait 5 years when Microsoft comes out with its next config file format (which will be about 10 years before its previous format actually caught on)...
Generally everyone comes up with their own format, because except for trivial configuration that's the easiest way to make sure it fits the purpose.

Actually, most applications today store a lot more of garbage in the Windows Registry. Most use custom classes and type libraries that have to be registered, also custom file types. Windows Installer installation process will additionally create many keys for the software. And when the application happens to run as a service (a lot of them have a service component), it will contaminate the System hive also.

Actually, most applications today store a lot more of garbage in the Windows Registry.

The Windows version of Apple's iTunes, which is one of the shittiest pieces of software ever written. It installs a shit load of files for 35 different languages. Gee, if only there was some way for iTunes to detect that I'm using the English version of Windows.

Then, just for extra shits and giggles, iTunes creates a registry entry for each one of those 10,000+ files. You can't make this stuff up.

You've been able to have really long paths forever in Win32, simply by prepending ""\\?\" to the path, which tells the Win32 APIs to not futz around with the path and instead just ship it straight down to the file system. If the file system itself can handle it, you're fine. There will still be other limits imposed, typically about 32K overall limit and 255 for each 'component', which is what they like to call each subdirectory or file that composes the overall path.

Actually, most applications today store a lot more of garbage in the Windows Registry. Most use custom classes and type libraries that have to be registered, also custom file types. Windows Installer installation process will additionally create many keys for the software. And when the application happens to run as a service (a lot of them have a service component), it will contaminate the System hive also.

I really wouldn't count most of those as they are created by the system, not the application directly. They also don't influence the way an application is configured (the point I was replying to from the parent). They are OS housekeeping to allow the application to find its DLLs and their entry points. I would also say that the vast majority of software does not install any services. Maybe 1% overall if you are talking desktop and not server software. Even then, if you know it does have one, it's easy to find in the registry (HKLM\System\CurrentControlSet\Services\ the usually either at that key or the \Parameters subkey).

The registry exists to make it harder for people to share software by copying files by themselves and require that software be "installed". Everything needs to be "installed" just to make an exe run, because the exe and related dll's need to check the registry to see if all the boxes are ticked. Before that you just had setting files that meant you could copy from one computer to another very easily.

Why not just turn this on by default?

Let me tell you a story about OpenVMS.

VMS, since it was created by DEC (RIP), has had a development policy of not enabling new features by default. It's been assumed with each release that you would read the release notes (which, by and large, are well-written) and enable any features that apply to your situation.

In OpenVMS, device IDs start with three alphabetical characters, followed by one or more numbers, ending with a colon (":"). Well, one day several years ago, HP decided that a change to increase the maximum driver device number from four digits to five digits was so awesome, they would make it the DEFAULT. Guess what happened to our code that only read four digits? Fortunately, we have sane programmers, so nothing stupid like a buffer overflow happened, as we trapped the error. But people who had their systems up and running long enough for terminal device numbers to read into the 10,000th digit (and VMS's reputation for reliability is well earned) would find themselves unable to sign into the application.

THAT is why you don't change system behavior by default.

It's just a data store. You're afraid of bits and bytes.

The registry is the wrong way to do it. It's accessible via Group Policy.

You're a fucking idiot. The registry is not meant to be played with, it's a good way to fuck up the computer.

I might suggest you're the idiot, as I've had no trouble editing the registry. Same for most of my colleagues.

If you're the only one who has trouble with it, the problem is probably you.

It's sort of rare, but you can occasionally run into path limits . . .

I run into it all the time when unzipping .zip files that have their own directory structure into the folder it needs to be on our server, especially since I've noticed lately that people are using longer and longer file & directory names. In my opinion, file names and directory hierarchies should be kept as short as possible, anyway, for good readability.

Most likely these apps will just get a path that cuts of after 260 chars and fail the same way they always did when a file was invalid or hogged by the anti virus of your choice. It is not like operating on the file system of a multi process operating system has ever guaranteed successfull file access.

Why not just turn this on by default? If this breaks some kind of DOS convention, then it's likely only relevant to enterprise users running some legacy crap, and assuming they run Windows 10 at all, I highly doubt they're going to upgrade to this build any time soon anyways.

Because it was not traditionally a registry setting but a compile time setting. Software has to be updated to use the new capabilities, and most software probably won't be as the majority of software dependent on this issue will have by now been upgraded to use the Win32 Unicode/Wide-String APIs that have the 32k byte limit instead of the 260 byte limit in the Win32 ASCIIZ/ASCII-String APIs (CreateFileW vs CreateFileA). And that's also assuming that a simple re-compile will do the trick; unfortunately most software often refers to the 260 byte character limit as either of the following:

260 (f.e char filename_buffer[260];
unsigned int maxPath = 260;

Better code would have used the MAX_PATH C-Preprocessor Definition (f.e char filename_buffer[MAX_PATH]), but then that would still be a problem as the values are usually on the stack (not the heap) and pre-declared, so the code has to be updated to detect the size automatically at run-time and then allocate the proper amount. For most software this is probably not worth it as its easier to upgrade to using the Wide-Strings with a the Win32 Unicode API, especially as there are a few conversion functions (provided by MS) to do so (f.e MBCSTOWCS() - https://msdn.microsoft.com/en-...).

The bigger issue (which is somewhat mitigated by the fact its disabled by default at the application level) is how many buffer overflows is it going to cause, not just in the applications but also the libraries the applications are using. Remember in Windows development a good chunk of the libraries are provided by other vendors without source, so one not only has to make sure *their* code will support the changes but also that all their dependent libraries (dynamic [dll] and static [lib]) do too.

The registry is actually fairly basic, it's just also huge and pretty poorly documented. Yes, you can screw up your computer pretty good if you do the wrong thing, just like messing with stuff in the system directory, or in ancient history, in the dos directory, but that's why you should be careful, have a backup, and don't play around or randomly experiment. Anyone who feels comfortable changing a simple registry entry is almost guaranteed to be able to do this without issue. Anyone who isn't probably doesn't even know what this change even does in the first place.

Well, that and extremely poorly maintained - in part on purpose in order to hide things (like license keys) across multiple registry settings (in part or in whole). But that is what really makes the Windows Registry a mess - you have no real idea where the value is coming from, and it's usually a PITA to track it down and change it successfully.

Remember C:\PROGRA~1\ ??

As much as I hate to admit it, there's a reason I knew exactly what that #define was, of course. I'm pretty sure I've done that myself at some point when writing some random Windows utility.

What's the alternative? 260 characters is just short enough to be impractical in some cases. This has nothing to do with *nix users complaining, as far as I can see. It's not a theoretical pain point, although it's not something most users hit every day either. Either MS fixes it incrementally, like they're doing, or Windows users have to live with that limitation forever. Given that you have to explicitly turn this feature on, it's not going to inadvertently break users for right now. If it's in a corporation, the admins likely won't allow that switch to be set unless they're certain *all* their critical software works with extra-long filenames.

This is the same sort of pain both users and developers went through when MS started getting serious about enforcing rules about where programs were allowed to write data. Yes, it causes some short term issues, but Windows is better for moving forward through some of these limitations and compatibility issue.

Probably just C:\by-GUID\{not-actually-that-long-guid}. MAX_PATH=260 already allowed more unique file names than there are atoms in the universe; the only reason for long paths is to have some meaning attached to the path components.

But note that the situation isn't new: you can already have executables with paths longer than 260 character today. The NTFS limit is 32K. That's because you could already tell Windows that you were _using_ long paths by prefixing them with \\?\, so you could also create (executable) files with such paths. But until now, you couldn't tell Windows that you _understand_ long paths.

You're a fucking idiot. The registry is not meant to be played with, it's a good way to fuck up the computer.

Just try deleting the contents of Windows\system and then we'll see who's a fucking idiot

There are still plenty of places in Win32 API where it has wchar_t[MAX_PATH] as member of structs and such. Increasing the length breaks ABI for all these.

In a few cases, however in a lot of places places where it looks like that, like for instance the directory iteration stuff, they only pack the current node into the data member that's sized to MAX_PATH, so it's still OK.

It's sort of rare, but you can occasionally run into path limits, especially with deeply nested computer-generated filenames, etc.

I have been having recurring problems on this point for well over a decade now, and it's one of the things the prompted me to move my persona stuff completely away from Windows about 8 years ago.

I subscribe to a number of scientific journals. Because it is common for me to be several hundred miles from a mobile telephone service, or a network of any sort, I keep those articles on local storage, because I literally don't know when I'll need to consult them. But how do I find them? Well, obviously the path needs to include the journal name, year and volume. For redundancy (because files do get misplaced) I put the journal name and volume into the file name too ; then I append the title of the paper so that I can find files relevant to (say) "West African Turonian limestones" with simple searches (rather than having to do deep inspection of every one of hundreds of thousands of PDFs. PArticularly with the titles, I've been bumping against file name limits let alone path+filename limits for years. It was never consistent between even current versions of Windows.

I do something similar with the family photos, with informatino stored in the comment field of the JPEG, then the comment exported to become part of the file name. Again, fairly long (150+ file names come with the territory.

It might be rare in your use case, but it has been a recurring problem for me, at home, for years.

I bet you really hated it when they moved on from 8.3 filenames too.

I can replace my Linux machine!

Why is this modded Funny? It should be modded Inspirational. Lets all switch to Windows!

*Winspirational

I'm guessing this innovation was partly in response to supporting WSL, so one can install Ubuntu on an ntfs filesystem.

NTFS doesn't have a 260 character limit, it is 32k. The limitation is in windows itself and seems to be another one of those limits kept purely for backward compatibility where a shitton of apps can't handle long paths.

Innovation? Really?

I have never written an app that specifically fucks up when 260 is reached. It will, however, catch an exception if the JIT compiler throws one and then fork an answer to to wherever. Which is VERY likely with all variants of Windoze as management like to write out sentences when 'managing' their folder structures.

It's the Year of Windows on handling email applications and RSS feeds.

Nah, the Windows way would be to patch system dialogs to create a temporary path to a virtual filesystem that maps to the correct file when a path over 260 chars is detected. It will work until you create a document that links to another document and tries to copy that to another computer.
Then they will add another api call to get the real file path to solve that issue.
Why create a good solution when you can just patch on top of the existing one?

I've always been amazed that on Win7 the Explorer program is unable to handle long paths. It gets even weirder when you discover that it can create some, but can't delete them. On numerous occasions I've had to resort to using Robocopy to /MIR an empty folder to the long path to remove it from the file system. On reflection, it would have been easier just to boot into Linux.

What sort of thing would you use >260 character paths for? I'm not questioning the need, I'm just looking for people with practical applications because it's interesting.

You mean you don't use your favorite Twitter comments as each branch of the file tree?

I have never written an app that specifically fucks up when 260 is reached.

Nobody do. But they write software that set aside 260 characters for pathnames, and don't check if any pathname is longer because the OS used to guarantee that could not happen. Then it happens anyway, and some other memory gets overwritten in a classic buffer-overflow error. Suddenly, someone throw a 32kB filename at your program. Or it connects to a unix network share where some joker created a 6GB filename or whatever.

I've got a build server that drops automatically named builds to a share. Automatically naming things with yyyyMMddHHmmss in the already quite convoluted descriptive title.

The limitation is also built into .NET for backwards compatibility. As a result, Powershell can't work with long file paths either. My understanding is that there are .NET libraries you can use to add the capability to your applications.

However, cmd.exe can access long paths. You can address UNC paths by using "\\?\[Drive letter]\[path to directory or file]". Most commands work. Rename is a notable exception because it interprets the '?' as a wild card.

It's a path length limit, not a file name length limit. Make your directories deep enough and you'll hit it even with short names.

I would move exclusively to Linux if it had support for most games but it doesn't. Microsoft has the market cornered on this with a lot of buy into DirectX. Cedega, Wine, Crossover, Parallels etc. just don't cut it unfortunately.

At work it happens all the bloody time. We have a very large file share, around 10 TB, of files generated when we do projects for our clients . Frequently our account execs will try to organize one of our larger client folders and end up nesting files and folders so deeply that the data becomes inaccessible. It's pretty easy to do when many documents are generated by mac users, who give zero fucks about file and folder name length.

Also, I will bet that if you fire up powershell and do a "get-childitem * -recurse -force" in your user directory you will get path length errors on files and folders under appdata.

It's quite a common issue on very large projects where there might be a network file system based file repository instead of a document management system. You'll quite often see insanely deep directory structures to keep things organized and try and let people find exactly what they are looking for (which seldom work, because there's *always* a bunch of files that refuse to be pidgeon holed like that). Generally not a problem on network servers, but when you try and copy a chunk of the directory tree over for offline access, almost certainly prepending everything with something along the lines of "C:\Users\$UserName\My Documents\Projects\$ProjectName\$FolderName\" in the process, you can get into some interesting issues depending on how well the file copy routine handles the error.

I've seen paths that tried to be longer than 260 characters with archives off of Usenet. Some idiot will use the filename as a text message. When it gets extracted the path becomes some_stupidly_long_200_character_filename/some_stupidly_long_200_character_filename.ext. Since the path then becomes too long, extraction fails.

The above isn't really a legitimate filename. It's being abused. But for a legitimate example, a common way to organize a HTPC movie collection is the format \Movies\[first_letter]\Title\Title.mkv. So Finding Nemo for instance would be \Movies\F\Finding Nemo\Finding Nemo.mkv. If you have a very long movie title (for example) then you legitimately would have a path too long if you used the full movie name.

There are easier ways.

Use MKLINK to create a symbolic link deeper into the path so that Explorer can work with a shorter path.

If it is a network share use NET USE to map a drive letter deep into the share path.

Use SUBST do do the same for local file systems, that is to mount a folder deep in the file path as a logical drive.

From a command line (cmd.exe) you can address long file paths with "\\?\[Drive Letter]\%File or directory path%". most commands work, but some, like RENAME will have trouble because it interprets the '?' as a wildcard.

The easy way to deal with this is to use subst command to assign the offending folder to a drive letter. You can then delete the files (now with a shorter path) from the virtual drive.

In the pwd of a command prompt or the address bar of an Explorer window, type "subst x: \". Then once the files are deleted, type "subst x: /d"

Mapped TFS workspaces. The TFS server repository might have a path like $/CompanyCollection/TeamProject1/Dev/DevBranch1/src/Solution1/Project1/Now/My/Project/Has/Folders/Too/. Then you map it into the common root folder for all of your dev work, which might very well make the final path something like C:\Users\MyUserName\Documents\Visual Studio 2015\Projects\CompanyCollection\TeamProject1\Dev\DevBranch1\src\Solution1\Project1\Now\My\Project\Has\Folders\Too\ and then you have a file named "SomeObjectNameThatIsProbablyTooLong.cs" and you've blown way past your 260 character limit. But because TFS can handle this internally (it stores it all in a database, not on the file system), and your mapped directory structure can't, you're screwed and can't get to your file anymore.

That's where I always hit the 260-character limit.

Users don't purposely use long path names, they unkwittingly copy/paste website titles and other long strings of text into the name of a folder since they lack the creativity to create a short and succinct name themselves, thus, they end up creating long folder names and shoving long named files inside them. I've had to support chemistry professors with PHDs and 30+ years of experience who manage to create archives of PDF files nest 3-6 folders deep with massive folder and filenames all the way down. Of course, they then complain when Windows prompts to run an autocheck every time their system is booted up.

Try copying your Users\{username} folder to a network share (as one does occasionally to back it up) and you'll be surprised at the number of times it cannot copy files because of length. The problem isn't usually the files you made yourself, but the \Games\Electronic Arts\Sid Meier's Civilization VIII Domination of Earth Edition\Saved Games\Automatically Saved Games\2016\January\11\10\President Abraham S. Lincoln United States of America\1048AD\Map\0000000000000000000000000000000000000000000000001.svdmap type files whose names are auto generated. This, incidentally, means the best user name to set up a new computer with is one character long (if Windows allows that, I have no idea, never really thought about the implications until now.)

What sort of thing would you use >260 character paths for? I'm not questioning the need, I'm just looking for people with practical applications because it's interesting.

I'm willing to bet that this is a reaction to companies moving to the online Office 365 service., and Sharepoint specifically. I get file path length warnings a lot of times when accessing team documents on our corporate Sharepoint server. It has a way of dealing with it, copy the file locally and then open it. But I'm thinking that they are being pressured to fix it.

Yeah, I figured it would be to cope with some stupid naming schemes. I was hoping that someone could demonstrate a sensible use for very long paths, but maybe not.

I remember people trolling the network admins with very long path names. If you create a directory with a long name, and then paste another directory with a long name inside it then back on XP it couldn't be deleted via Explorer. You had to use a command prompt and the 8.3 name.

That was in the 2000s though, back in my day it involved putting "spaced" in DOS file names by typing alt-2-5-5. Or better still put the space at the end of the file name.

IIRC, NET USE has an 80 character string length from the command line interface. It's a stupid limit that doesn't exist in the actual Win32 API, but the way it's exposed from cmd.exe is... special. If anyone is curious, here's the discussion around the max share name lengths, etc. that I added to the Samba CIFS client mount utility and the Linux kernel side code.

I've seen ~4K paths in older browsers cache mechanisms since at least NT4, composed by taking a base directory and appending some additional info that included the encoded URL. I had to fix a bug where this was a problem when a stock tracking page was accessed with 'too many' symbols specified. I assume the browser (I believe it was IE, but I wasn't working on the browser so I don't recall for sure) was using "\\?\" properly to form those paths.

I've occasionally exceeded it with company or department file servers that have deep hierarchical organization.

Artist/Album Name/Track Name.mp3 where all three names are practically sentences. Pretty much any time a filename is set to the actual name of an artistic work has reasonable odds of causing the problem at some point. It's happened with books and movies before as well, just far less often.

I also sometimes run into archives that get extracted into an extremely long directory, often two levels deep with the same filename. Or archives created with the entire path from root in them (coming from a linux system).

And it all gets worse with highly hierarchical systems. For example, this may not be brief but it's not crazy at all, and won't hold up under long names: /Backup/YYYY-MM-DD-mmmmmm/Shared Files/Archives/Television Shows/Comedy/Long Series Name/Season 1 (2012)/s01e01 - Episode Name.mp4

There's really no reason to have the limit, it just causes frustration.

What sort of thing would you use >260 character paths for?

We used to hit that limit all the time where I worked.

We used directory structure to organize all of our product releases on the server. Here's the kind of naming template we used:

\\Servername\Sharename\ProductEngineering\ReleaseArchive\ProductName\ComponentName\Version\Deliverables\PlatformName\CDs\CDName\...

Where the "..." at the end would contain additional levels of subdirectories that mirror the structure of the files that we release on the CD.

Once we expanded all the names in that template, it easily blew past the 260 character limit. Our solution was to establish a lower-level mount point, so, for example, the first 4 levels could be collapsed into a single name, saving us about 50 characters.

What made the name especially long for us was the fact that we always needed to make sure that intermediate subdirectory names contained full identification information, so that there would be no possibility of name clashes in case we copied the subdirectories elsewhere (for example, to a FTP server). Thus, the "Version" (in the template above) could not be something simple like "3.5.0.1455" -- we needed the "Version" to include full, unambiguous ID information, like this: "AutomationRobot1200_AuxiliaryControllerModule_BaseMotorFirmware_3.5.0.1455". Of course, that version name includes some redundant information that could be determined from its parent directory names, but that redundancy allowed us to copy the version directory and be guaranteed to retain easy visibility of all necessary ID information -- a small detail which helps avoid potential confusion, which turned out to be a surprisingly important goal.

But your "Movies" folder is inside Microsoft's "Documents and Settings and other shit you might maybe possibly want to throw in just in case you might need it in ten years when this system no longer works" folder.

:-) You gotta archive (and gzip if you want) it first

Nah. It's on it's own drive managed by Drive Bender.

Not quite "Windows itself", but rather the Win32 subsystem. The NT Kernel has the same limit as NTFS; but virtually everyone works on the Win32 subsystem that runs on top of it, and THAT is limited to 260 characters.

There are other differences: NTFS and NT Kernel is also case sensitive, for example. The Win32 API on top isn't. NT Kernel doesn't care about a file called "CON", but the Win32 system will. This is why sometimes \\?\ prefix lets you reach strange files - it tells the Win32 system to 'don't try and understand this path, hand it to NT and NTFS exactly as is", but I don't think it gets past this limit.

That's the interesting thing with Ubuntu on Windows - because it's running as a separate subsystem against the NT kernel API (i.e., NOT part of the Win32 subsystem) it should only face the 32K limit and be able to use NTFS's native case-sensitivity and all the other Unix-filesystem-support that's been in NTFS for a long time.)

I have a teeny little photo gallery which has to handle paths to cache in some random location. The filename contains the original name plus the size. Sometimes people use some pretty long filenames to identify pictures. I handle it on Windows by catching the exception and instead using a hash for the filename. If they ever remove the limit, the exception won't be hit anymore and it'll act like other platforms. On Mac, the same code throws an exception when filenames are too big (255 characters), and the solution is the same.

npm can easily produce a directory tree that deep due to the way it handles dependencies.

To be more specific, the limitation is in Win32, and it's really an ABI/API thing (i.e. it's easy to increase the limit, but you break everyone who was relying on it). If you use NT APIs directly, you don't have that problem.

This has always been possible in Windows NT, but the shell kept limits in place for backward compatibility. Expect older application to break in deep directories or with any path that otherwise exceeds MAX_PATH characters.

The compatibility issue is likely exactly why it's limited to Win32 applications with a manifest and Metro apps.

Right, leaving behind files inaccessible to older applications.

Not to mention creating an ever longer list of things to do when you start writing a Windows program
1) Enable NX
2) Enable ASLR
3) Disable loading and running dlls from random web servers just because the user opened a file from it at some point
4) Disable sending error reports to Microsoft (at the very least if it's a somewhat confidential internal application)
5) Disable prompting to insert a floppy/CD/DVD if it none is inserted and you try to open a file on that drive, especially since that feature has gotten ever more broken and unpredictable over the years
And now
6) Enable long path names
I probably forgot a few though. What's the point of all those crappy defaults? After all Microsoft already implements a compatibility mode. If you need to use old programs, you'll just have to tell Windows it's old. Saves everyone a huge amount of pain and security holes over sticking with "default to insecure and buggy unless the developer remembered to tick all boxes".

This has always been possible in Windows NT, but the shell kept limits in place for backward compatibility. Expect older application to break in deep directories or with any path that otherwise exceeds MAX_PATH characters.

command.com (being a DOS shell out, operating in 16-bit DOS mode) had the 256 byte limit, but cmd.exe (being a proper Win32 API oriented command-line shell) has had the ability to use the Unicode (\\?\) paths since at least Win2k, if not before that. The tools available under cmd.exe nearly all support the Unicode filename format and have for a long time. That was one of the big draws for using cmd.exe over command.com - less restrictions in use.

I no longer have to maintain a relatively flat file directory structure? My directories can finally go to... plaid?!

I'd go straight for paisley or argyle, or perhaps Nova Scotia Tartan.

I want to be excited about Windows 10 but I can't. Please, please, please give me an official option to turn off telemetry like the Enterprise version has. I'm also interested in the Long-term Servicing Branch.

Thanks,
A home user and family IT guy.

Dear Family IT guy,

Thank you for choosing Windows as your OS. While we understand your concerns, we don't give a fuck. We want your data and we're going to take it. If you were going to switch to another OS you would have done it after Windows 8, but you didn't, so bend over and take it. Take it! Squeal like a pig! Squeal you little shit!

Sincerely,
Microsoft Support

Far too direct a reply for it to be MS. :P

I want to be excited about Windows 10 but I can't. Please, please, please give me an official option to turn off telemetry like the Enterprise version has. I'm also interested in the Long-term Servicing Branch.

Thanks, A home user and family IT guy.

Are you new at this? Just curious, because Microsoft hasn't been listening to their user base in years.

Oh, and the Enterprise version will be fixed soon with the next round of involuntary updates, so don't worry about being left out from those telemetry "features"...

I want to be excited about Windows 10 but I can't. Please, please, please give me an official option to turn off telemetry like the Enterprise version has.

So if you just want to disable telemetry, in registry key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DataCollection create a 32-bit DWORD called AllowTelemetry and set it to 0. Restart Windows for the changes to take effect.

I want to be excited about Windows 10 but I can't. Please, please, please give me an official option to turn off telemetry like the Enterprise version has.

So if you just want to disable telemetry, in registry key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DataCollection create a 32-bit DWORD called AllowTelemetry and set it to 0. Restart Windows for the changes to take effect.

If you're correct, that's great news. Could you please the reason you think that's a reliable approach?

The best way to turn it off is to get a glass of water and pour it into your computer.. repeat until sparks fly...

This doesn't work on Home or Pro editions. It's equivalent to setting feedback/diagnostics to "Basic" which still enables a minimal amount of telemetry. (http://www.askvg.com/truth-behind-disallowing-telemetry-and-data-collection-trick-in-windows-10/)

Not that I don't think people who have a problem with small amounts of software telemetry aren't ridiculous as it's almost garaunteed that many other devices and software they use also have telemetry features (eg: video game consoles, phones, cars, etc)

Hm?

Too bad for other versions of Windows (and *nixes) when they encounter removable drives using these new path limits.

260 characters ought to be enough for anyone!

Linux has supported MUCH longer paths for a long time. In fact, it's only limited by the limits of the underlying filesystem. It's Windows that artificially restricts them instead of obeying the FS limits like it's supposed to.

260 characters ought to be enough for anyone!

I have to agree in this case. If you need more than 260, you are probably doing something stupid, and the few cases where it's not stupid are overshadowed by the vast majority that are.

It appears that in some industries workplace health and safety documentation policies are exactly that kind of stupid. Why I have no idea, but so many tedious artificial emergencies have cropped up from people losing access to their stuff due to insanely deep nesting with even more insane long filenames.
The really hilarious (after the things have been recovered) side of it is being able to write stuff with a long path but not being able to read it back later.
"I've got a meeting in five minutes and I've copied the files so deep that the sun doesn't shine on them" proves the wisdom of having the files on a fileserver under adult supervison of an OS that can actually get to them.
Good to see that problem is going to go away.

At one time, Bill G said (or it was reported he said) that 10 megabytes would be more than enough storage for anyone.

The problem is not going away, just changing. Just because the system allows huge (deep) paths and file-names doesn't mean people will know how to use them. It may confuse them enough that they cannot find or manage their files, and complain to the help desk.

It's like building a pickup truck that can accept giant tires. Fools will put 40-foot tires on their trucks to be big-shots or because somebody told them it's good, and crash into regular folks.

True, a technical problem has gone away but stupidity can still remain.
Those directory names I was writing about have punctuation in them! Commas, semicolons, everything apart from asterisks. You can get to them nested deep on a *nix filesystem but it's a pain.
People blame quality assurance systems but the initial guidelines don't mandate such stupid implementations - it's just someone doing something really stupid and others copying them in between Facebook employee stalking and farmville or whatever the latest game on there is.

If my memory serves me correctly the feature was in WinNT

Registry entry might be different, tho

While this might work for new applications and may work internally, there are a fair number of C++ applications out there that use the pre-defined MAX_PATH preprocessor define to allocate an array on the stack to receive a path. Such as:

TCHAR filePath[MAX_PATH];
GetSomething(hFile, filePath, sizeof(filePath)/sizeof(TCHAR));

This code is already compiled to a fixed size buffer to receive the path. Mostly because this is what was in all the Win32 examples and best practices guides. Fortunately, these functions still take a length of the buffer so I don't think we'll run into any buffer overrun issues, but they would just fail to work with the long paths until there is some type of API call to get the size of the buffer we need to allocate.

easy fix: just recompile.

closed-source software? well now you've identified your first problem. ;)

Sure, everybody with a personal computer should just recompile. Even the 99.9% of people who don't code, right?

Your package manager can do the recompilation for you. No special knowledge is needed.

No package management in your system? Well, now you've identified your second problem! :)

Obvious bug there.... at a minimum it should be "TCHAR filePath[MAX_PATH+1];"

or you can have a buffer overflow if you use exactly MAX_PATH characters in the path...

Its Windows - no compiler either.

easy fix: just recompile.

So your solution is that a business should purchase that source code from the vendor, hire developers and testers to fix, test and maintain the code?

Have you, you know, actually tried doing what you're suggesting?

easy fix: just recompile.

So your solution is that a business should purchase that source code from the vendor, hire developers and testers to fix, test and maintain the code?

wrong on all counts! my solutions is not using closed source to start with!

Software does not spontaneously come into existence. If a business wants software written, they have to contract a vendor to do it. Try convincing a business to pay extra for the source code as well.

you can use existing open source software or contract someone to modify an existing open source program. in both cases the resulting source code is free for all. also, if a MBA wants to shoot their company in the foot, the company should do something about it. if all the MBAs in the company wan to shoot their company in the foot, that's darwinism.

also, if a MBA wants to shoot their company in the foot, the company should do something about it. if all the MBAs in the company wan to shoot their company in the foot, that's darwinism.

You might find it hard to convince a successful business that they were wrong to go with closed source software, or not pay extra money for the source code.

they don't have to be convinced of anything, they can live with broken software or pay to replace it. reality won't change because an MBA thinks it should.

That does not make sense. If the path is too long to fit in the buffer the software could not work anyway, since the text returned cannot be the correct path name. So I agree I don't see what the problem is and why this is not the default.

Prior to this change, the path could never be too long to fit into the buffer, Windows wouldn't allow it. Windows only allows a maximum path length of 260 characters, anything more is considered an invalid path name. The total path length including directories could not exceed 260 characters.

This is exactly why it requires the application to declare support for longer paths in its manifest.

MAX_PATH already includes the null terminator.

The reason why it is 260 chars, in fact, is because it's 256 chars for the path from the root of the drive, plus 3 chars for "X:\" prefix, plus 1 char for the terminating null.

I know you are trying to imitate Microsoft managers, but you are being too respectful and friendly to sound much like them.

Microsoft managers train with the airlines.

Now if we could only use common punctuation like question marks and colons in file names...

Since the windows registry was invented, Microsoft have added way too many configurable values whose only purpose seems to be to trap the unwary. Delete any of them and your OS will become unusable in weird ways.

Yeah, whereas with other OSs, deleting random configuration data has no effect.

Have you ever run ProcessMonitor and performed some mundane action in windows explorer?

No.

Keep laughing, how many system critical variables is systemd in charge of now?

Comment removed based on user account deletion

This isn't just something you can switch on without thought.

Windows' native programming has long had a "MAX_PATH" constant, which devs would use to create a char[MAX_PATH] to accept user input (i.e. from a save file dialog). If you suddenly start creating paths larger than this, you risk buffer overflows.

Even if your app is carefully written to avoid buffer overflows in this situation, it may simply refuse to read the file with a path too large. Devs have been able to break beyond MAX_PATH for a while by using UNC paths, but almost nobody uses them because you'll find random apps that won't know how to use a longer path.

I find it a bit weird that they haven't taken an approach similar to high DPI, where you can embed a manifest resource into your app that'll tell the OS it supports high DPI. While this would not solve random apps refusing to work with larger paths, this would at least prevent buffer overflows.

And in true old-school Slashdot fashion, I've apparently skipped over a paragraph in TFA. Using manifests is exactly what they've done.

the possiblity has been in there kind of long time already for it to happen.

what it is actually used is for.. drumroll... making hidden paths!

why? so you can stick your ntfs on the fly replacement executable images there. in other words malware & etc. due to to that and some symlink crappery it's been possible that your win32 apps receive filenames longer than 255 a long time already. they wouldn't be able to read them of course, which has been the whole point.

the user dialog might provide something longer anyways, it's not like you can trust it.

Notably, windows file explorer never used to allow file operations on >260 filepaths.

Windows' native programming has long had a "MAX_PATH" constant, which devs would use to create a char[MAX_PATH] to accept user input (i.e. from a save file dialog). If you suddenly start creating paths larger than this, you risk buffer overflows.

It appears Microsoft assumes that only shitty programmers write code for Windows. MAX_PATH is a compile-time constant (#define in windef.h). Even if you declare char my_path[MAX_PATH] variable (surely, you mean char my_path[MAX_PATH+1], right?), you wouldn't just pass it in into some other function expecting exactly MAX_PATH characters to be written into it, right? Surely, you'll also pass in MAX_PATH as the number of chars you are expecting to get, right? Something like strncpy( my_path, other_path, MAX_PATH ) instead of strcpy( my_path, other_path ). Right? Right?!

Notably, windows file explorer never used to allow file operations on >260 filepaths.

Midnight commander for the win(dows)!

Windows' native programming has long had a "MAX_PATH" constant, which devs would use to create a char[MAX_PATH] to accept user input (i.e. from a save file dialog). If you suddenly start creating paths larger than this, you risk buffer overflows.

It appears Microsoft assumes that only shitty programmers write code for Windows. MAX_PATH is a compile-time constant (#define in windef.h). Even if you declare char my_path[MAX_PATH] variable (surely, you mean char my_path[MAX_PATH+1], right?), you wouldn't just pass it in into some other function expecting exactly MAX_PATH characters to be written into it, right? Surely, you'll also pass in MAX_PATH as the number of chars you are expecting to get, right? Something like strncpy( my_path, other_path, MAX_PATH ) instead of strcpy( my_path, other_path ). Right? Right?!

And then you get some user input that makes your app open /mydir/longpath/file, and your app opens /mydir/long instead...

MAX_PATH includes the null terminator.

Which could still leave you without a terminating null unless you were first careful to memset(my_path, NULL, MAX_PATH +1); right?

Its also not like truncating a path could not lead to any sort of undesirable side effects.

But no thanks ; not using OSes that have registries.

Including systemd, which populates its hives like Win95 did, from MSDOS .INI files.

So... OS/2 is fine?

Every OS has a default place to put configurations. I take it you don't use computers then?

Indeed, some places are messier than others. The "registry" is a big awful mess.

systemd does not have a registry, it as you point out uses a configuration format that looks like the old MSDOS ini files. The problem exists with the registry, not with the ini files (Lots of other applications uses ini file style configuration syntax).

Why? I've heard that many times but never heard a reason for it. Messing around with the registry is fun, it can also be easily backed up and copied, etc. What's the problem with it?

Don't get me wrong, I'm a former Mac user and use GNU/Linux as my main OS, Windows 7 only for audio recording and gaming. I'm really not a fanboy, just wondering.

This is not an NTFS problem but an old API problem that programs should have stopped using years ago (decades, actually).

Programs like the NPM Nodejs package manager have had, until recently, horrifically long pathnames for no good reason. This fixes that for them.

Nearly any other program doesn't have this problem.

Good job, NPM developers, for forcing MSFT to update a very old API that you still insist on using.

CON? LPT1? COM1?

This will be a great improvement. I have Windows 10 running on my IoT garden GNAAomes and can't wait until they have this functionality.

Their obsession with using UUIDs (36 characters long -- each) frequently rendered certain directories unbrowseable.

And for those of us who like annotating our media collections with descriptive file names, 260 characters was easily not long enough.

I don't imagine there are many people who are just dying to have filenames longer than 260 characters.

path names, not file names. Its quite easy when a file is buried a few levels deep. Especially with symbolic links.

Not file names -- file PATHs longer than 260 characters.

As in:

"C:\Users\Fubar\Pictures\Vacation\2013\Hawaii\Dole Plantation\Silly Photo with Sister 023.jpg"

Obviously, that's under 260 characters, but if you try copying an entire user profile to another computer's desktop folder "C:\Users\Foo\Desktop\old profile", you get an even longer character path... and some people have very elaborate Documents folders for work and school projects that are many nested folders deep and lots of characters for descriptions.

I've hit the character limit more than once myself -- especially with MP3 files with full band and song titles in the name and a few project files, but I've hit it multiple times copying entire profiles to servers as backups before swapping out a machine.

Oh. Whoops. Fair point.

I used to work in post-production. 250 characters was quite often not enough for many structured file hierarchies. It's one of the reasons our dataops department did not use Windows for file transfers.

Since I work for Microsoft, we're forced to use that Windows garbage. We have a lot of deep paths, and we're constantly having problems with paths that are too long. It's gotten to the point where we have to checkout subtrees instead of the entire tree so we don't hit this bug.

This! We can't use Git and are still stuck on subversion since it allows checkouts of part of the source.

I know you guys have had trouble with longer usernames because of this problem. My roommate's last name had to be truncated in order to sneak part of the source under this ridiculous limit.

Our company is involved in a project where the 260 char limit is a big problem. The git repository is essentially a copy of a portion of a Java content repository with quite a deep structure. If you tried to clone it into your documents directory on Windows, the 260 character limit was guaranteed to be hit unless your login name was something like "Bob".

It's driven me nuts for years. Things will randomly fail and I have to move folders up to a new root or shorten the name of folders along the path. The fact that some programmes haven't had a problem whilst others do has just compounded the problem.

Mercurial stores working copy metadata with filenames with capitals E_S_C_A_P_E_D_ W_I_T_H_ U_N_D_E_R_S_C_O_R_E_S_ - it's even worse, it can't even version control trees that the API can cope with.

Wow, you changed your mind quickly! You don't seem to think that wanting to do "very-descriptive-title-goes-over-260-chars.dat" is reasonable, it's more understandable with a short named file buried in subdirectories spelling out to more than than length?

Uhh, no:
https://www.mercurial-scm.org/...
Unless you're stuck with an eight years old release, that is.

This was quite a long time ago (first half of 2008), so my information is out of date. It does seem like the sort of thing that would have been fixed, though.

I was assessing version control systems for an internal project. Git was not ready to work properly on Windows, and hard for normal users, Hg had that bug, Subversion was too slow (12 minute checkout time for the trees concerned.)

Bazaar came out on top. It worked properly on Windows, was 3x faster than SVN on Windows (and moved up to being more like 6-8x faster, and was always MUCH faster on Linux).

Everyone has nested directories.

If I unpack a tarball or zipfile I don't want there to be any likelihood that it'lll fail to unpack in some places because the total length is pretty long. On the other hand, I don't care about bizarrely long filenames - almost nobody does that.

That's been fixed for a while. It internally stores things that would be too long in a different filename.

We still use Netware here. No spying, no Windows 95-era path-length limits, No facebook integration, etc..., easy to back up.

Because as stated in another thread, MS/W devs do `char path[MAX_PATH];` So if MS removes the limit most programs will stack overflow.

Is this the last legacy from OS/2 to be removed?

They really are getting desperate to find reasons to get corp clients to "upgrade" to 10 from 7.

People will not "upgrade" because they need this feature.
People will "upgrade" because other people will use this feature and thus cause interoperability issues.
Standard Microsoft practice.

Yeah, I can see whole city blocks of dev shops starting up and finding new ways stuff those files paths as long as possible. Eventually, all files will have had every scrap of data and metadata pulled out, base64 encoded or similar and stuffed into the pathname. A 4GB movie file would simply become a ~6GB pathname. Actual files would be unnecessary, just directories and their names, lovely long make Microsoft money names!

npm isn't the problem. npm uses node, and node does all filesystem access through libuv. libuv can handle long paths on Windows. If npm only had to worry about itself and other node-based programs, everything would be fine.

The problem is that npm sometimes needs to run external programs, and these often fail with long paths. In particular, the Microsoft C++ compiler and linker don't handle long paths. So, npm is unable to build native code modules.

The summary mentions that it will only be available to manifested applications, i.e. ones for which the developer has already indicated it can deal with longer paths. Given that protection, there is absolutely no need for additional protection via a registry key.

there is a need. To avoid many many support calls (or calls to the helpdesk) with questions like "I just copied some files but Program X can't see them. WHAT DID YOU DO TO THEM?"

The/question/I/have/is/why/would/you/want/a/path/that/exceeds/260/characters/in/the/first/place

because/java/weenies/like/to/make/unbearably/long/paths/which/serve/double/duty/as/class/namespaces

Yet another reason to hate Java

Sure there is a need. Lots of work flows require multiple applications. You don't want someone creating a file with application A they wound be able to read with application B. That is the kind of thing users generally can't understand and tends to result in lots a helpdesk calls.

I can see why enterprises might want the option to turn this off.

there is a need. To avoid many many support calls (or calls to the helpdesk) with questions like "I just copied some files but Program X can't see them. WHAT DID YOU DO TO THEM?"

You do realize that problem already exists, right? Explorer has supported 32k pathnames since at least XP. Apparently the problem is not as common as you are suggesting.

Explorer has supported 32k pathnames since at least XP

I disagree.

I am using Windows 8.1 and, right now, and I have paths on my computer that were created by npm that I cannot delete via Explorer. I use Tools-RecursiveDelete from github when I need to delete those folders.

(Posted AC cuz I moderated)

Yes, yes you are, mania guy.

I was at a company which developed a large CRM application and I was the person who tarred up software updates to send to sites. A small part of the application was in Java, and the Java programmers were enamoured with class names which emphasized descriptiveness over brevity. We ended up with some files where path+filename exceeded 255 characters, and tar broke. My fix was to tell the programmers to shorten their damn file and directory names. (This was about 15 years ago, and it would have been Gnu tar. )

That's actually funny.

Whilst paths could theoretically be any length on UFS, there was (actually still is) a #define called PATH_MAX which practically every programmer used to allocate buffers to hold paths. According to Posix, the absolute largest this define can be is 256 (fortunately, Linux ignores this and goes for 4096).

I bet there is a lot of Unix code out there that breaks, possibly in subtle ways when paths exceed PATH_MAX characters.

I assume Windows 10 Redstone requires a dedicated Minecraft world to execute in.

Yeah, I was wondering if they only bought Minecraft so they could use their codename.

Prepend "\\?\" to the path to tell the standard API to ignore MAX_PATH. This is how Robocopy and many other tools work around the issue.

I know, but you do have to dig pretty deep in the documentation to find this particular gem. However, if you want to *get* a long path back from a Windows API call, then this trick doesn't work.

True... Haven't tested but I wonder if this will cover powershell/.Net

None of the currently shipped versions of the Framework will support paths longer than MAX_PATH, but .NET Core will: https://github.com/dotnet/coreclr/issues/1776

True. Node is literally the only time that I've run into this problem in my entire career. Maybe I've led a sheltered life, but still....

Perhaps in a weird situation you might want to protect a badly coded application from the longer path length?

Due to the design of the Windows API, almost all applications are 'badly coded' in this respect.

And allow us to use files called CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9.

Or use of <, >, :, ", |,?,* characters.

Or the other strange arbitrary rules, e.g. spaces allowed in names but a filename must have something other than spaces in it. There are many others.

But Linux also should probably not limit file paths to 4096, I'd have thought that might start to be an issue for people using a lot of Unicode.

I'm just afraid that it will 'Brick" my older systems. Possibly by design.

Great. Microsoft can now hide their spyware apps to such a deep nested path level that it will be almost physically impossible for a user to drill down far enough to remove them !

As an added bonus the randomly generated names will contain special characters that Windows Explorer "can't" handle so you'll be forced to type the path out by hand in a DOS prompt. Which will then fail as the "path is too long".

Hmmm...I just checked IRIX 6.5.29, plus Solaris 10 and 11- it says 1024, but also defines POSIX_PATH_MAX to 255

Great!
Now if only I could resize a whole slew of windows....I know its new tech, and very hard to do, but pulling at the edges of a window SHOULD let you RESIZE IT...
hold on to your gravy grandpa!
Just the most relevant example, the path window itself in windows does NOT let you resize it, there are also several in visual studio which have huge lines in them, but nope, can't resize them, they are the perfect size!

I was at a company which developed a large CRM application and I was the person who tarred up software updates to send to sites. A small part of the application was in Java, and the Java programmers were enamoured with class names which emphasized descriptiveness over brevity. We ended up with some files where path+filename exceeded 255 characters, and tar broke. My fix was to tell the programmers to shorten their damn file and directory names. (This was about 15 years ago, and it would have been Gnu tar. )

It depends on the file format you were using (which was whatever the default was). There are actually a few "tar" formats that have different limits:

https://www.gnu.org/software/tar/manual/html_section/tar_68.html

Not sure what it would have been 15 year ago; probably depends on the exact version of tar. Another option would be to use Schilly tar ("star"), which has (had?) some advantages of GNU:

http://wiki.zmanda.com/index.php/Star

BSD tar is also used in a lot of places. See also "pax".

Because as stated in another thread, MS/W devs do `char path[MAX_PATH];` So if MS removes the limit most programs will stack overflow.

You may mean buffer overflow here.

The declaration you've quoted would be resolved at compile time, not run time. So if MAX_PATH was 260 at compile time and then run on a system where the runtime behavior allowed for longer paths, I could certainly see a buffer overflow condition happening. But the program will only ever allocated 260 bytes off the stack in that case, so stack usage would remain the same.

And I assume if MAX_PATH were _UI64_MAX (or whatever) at compile time, the compiler would complain.

But Linux also should probably not limit file paths to 4096, I'd have thought that might start to be an issue for people using a lot of Unicode.

First, even with three-byte UTF-8 on average, that's still 1365 characters.

Second, apparently that 4096 limit was removed, and the constant only exists because the standard says it has to exist (but then again, the standard says it can be no more than 255). The individual file systems may still have other limits, though.

The might stack overflow, depending on how they are written they also might do other things. I bet there is a fair amount of strncpy(foo, bar, MAX_PATH); out there as well. Which could lead to strings that are not null terminated but also don't overwrite, the result probably being some kind of crash when foo is read, the other possibility is truncation. A Only the first 260 bytes of path get copied the result is some later action is taken on the partial path. Maybe that fails, maybe that results in a new file, maybe something like a temp file is create but not deleted by a later clean up routine filling the disk who knows.

This could cause any all types of chaos.

Linux and others could do that for decades. Nice to see that Microsoft is catching up and removes the remaining DOS limitations. I guess it is asking to much to have them backport this to Win7/8. In which build to they do away with drive letters? And when is NTFS replaced with a modern and performant file system?

NTFS isn't the problem. NTFS supports up to 32k character file paths as well as a number of characters that windows deems illegal. This is a problem with the Windows API's and .Net. I frequently work with long paths in windows (as dictated by necessity, not by choice) by addressing UNC paths at the command line, or by mapping drive letters or creating symbolic links deep into the directory tree.

The look on people's faces when they find out why sharepoint can't handle folder nesting is priceless

It should be:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies -or-
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem

Credit goes to user foobar in the article's comment section.

I misread that as MSJW devs, and now I'm really hoping that doesn't become a thing.

The idea is the guy assumes that no path will have a longer length than MAX_PATH. So for already compiled programs (before win10 option) the guy may `strcpy` into `path` any path given by the system with no much care. This would be indeed buffer overflow. But MAX_PATH may be given a much larger value by default in the new win10, in this case stack overflow... (and likely a warning by the compiler).

Undefined behavior, indeed.

Come on, if 640K is enough for the whole damned program, 260 bytes should be enough for a filename. In fact one digit is enough for Windows version numbers.

oh!

wait.

You mean v3 of npm and its nested modules wasn't the issue?

Back in the day when most engineering applications were on unix machines and they were being migrated to windows workstation, the path name limitation was a big issue. PTC (Parametric technologies corp, a vendor of CAD/CAM software) would typically use a MAXPATHLEN of about 10*BUFSIZ but user can configure it to be bigger if they needed it. And its parts libray used very long hashes for file names. Everything from part name, author name, version number, creation date gets munged into the file names, bearing_housing_djt_284985473754653746544v .prt or something like that.

They found the 8.3 file name format very confining. So they did a simple hack. They would construct the file/path name just as they would in unix. Then send it through a string processor that will insert a "\" after every 8th char and keep creating sub directories to get the file name they wanted! User will see humongous file names and path names.

Our company has been supporting 4K path names now, I remember setting MAXPATHLEN to be 1025 (remember to allocate space for the trailing null) back when joined the company decades ago.

You're missing the point. Paths are supposed to be dynamically allocated to allow any length. Static paths will eventually fail at some time.

All file/path names are always allocated dynamically in our code. MAXPATHLEN is used limit user input in dialogs. This is necessary to protect against buffer overflow vulnerability. Copying and pasting humongous amount of data, including control characters and non printable characters into edit boxes are one of the oldest hacking techniques. We NEVER allow unlimited amount of data from any user input field. All user input goes into a preallocated buffer, never an overflow. Then we filter out irrelevant and unreasonable characters in the input. This is true for ALL input fields. If the input field is file name it has one validation rule, if it is a double it has different data validation rule.

Of course Microsoft probably used fixed length buffers some time in the distant past to shave a few micro seconds off the dynamic allocation time. By the time code was copy/paste\ed in so many places and in so many modules, it gets carved in stone and becomes very difficult to change.

That's assuming the variable is on the stack. In many cases it will be on the heap.

I use CON regularly. NUL infrequently. COM and LPT, never anymore, nor AUX.
I use and | and ? and * regularly.

Not in filenames, in command lines.

C:\> copy con test.txt
File not found.

Noooooo

I misread that as MSJW devs, and now I'm really hoping that doesn't become a thing.

Their code would never run successfully:

- They'd consider it every program's right to call abort(); without being criticized.

- They could only use peer-to-peer architectures, as master / slave is oppressive.

- All branching logic would initially be floating-point -based, as Boolean logic is exclusionary and thus a micro-aggression against LGBTQ culture. However, it would later be decided that forcing branching logic was inherently judgmental, and thus all program instructions must have an equal chance to execute every processor clock tick.

The one upside is that their code would be meticulously designed to avoid race conditions. Sadly, it would also be subject to nearly constant deadlock.

We've had to use robocopy et al to delete too-long-named directory trees for how many years now?

I normally run into the character path length limit when performing a copy of user files within Explorer.

Users will often type descriptive names for files but they don't have knowledge of character or path limits.

It seems as though this has been sort of "half assed" implantation for a long time in Windows where some programs (including MS's own stuff) use old API's which enforce the limitation and other programs use newer APIs (or just do stuff directly) and work around the limit.

This created many cases in which these files and paths can exist on the file system and can be accessed by some applications but not others.

It's not a life altering change, but I welcome it. I am hoping this is the start of some long standing bug fixes.

And what can I use such a construct for?

Will this make my google apps faster?

How about my iCloud or instagram?

Oh wait, I understand, I'll be able to tweet longer tweets! That's it!!

256 is th minimum allowed value to be POSIX compliant. Think real hard I bet you can guess how that value ended up there. I don't think there's ever been a *nix below 1024.

Does anyone remember back in the day when you could BSOD Windows 9x machines by calling CON, LPT1, COM1 in an IMG HTML tag?
<img src=LPT1>

Long names may be great for making very descriptive names for your files and folders, but they also increase the time it takes to find stuff. When you want to find all of your .JPG photo files by traversing your file system looking for any files with that extension; then be prepared to wait a long time if you have a lot of files and even longer if your names are really long. It takes many more processor instructions to process each string looking for patterns or file extensions. If you only have a few thousand files, then you might not notice it, but put 10 million (or 100 million) files in one of your volumes and you certainly will.

PATH_MAX is the length of path gauranteed to work on this OS (and can be different for each OS).

POSIX_ PATH_MAX is the lowest value of PATH_MAX allowed on other POSIX systems, which could matter for network communication etc. It's 256.

This will be a necessary change when you have literally billions of billions of files... duh...

Why does this fact need a whole article on slashdot. Max path length has been 4096 on Linux for ages.

Some languages smush together a bunch of adjectives & tack on a noun: presto--unambiguous file/folder names! If translated, you still get a paragraph-long path, but now with spaces.

subst and robocopy are your friends!

Unlike Linux, Windows is focused on letting programs that are already working, continue to work for decades without a single recompile. Windows has to build defenses (like not allowing > 260 char paths) for programs written using fixed sized buffers. Or having an entire division of people dedicated to writing shims to so buggy programs that rely on undocumented behavior continue to work in newer versions. Instead of letting the users suffer because of developers' mistakes or when vendors go out of business.

These sorts of ideas are the result of a mature person dealing with the reality of their current situation and coming up with solutions instead of pointing fingers and looking for things to blame.This is why Windows has and will continue to dominate.

You people wouldn't understand it. Its okay.

get grown-up security, mandatory access control like SELinux and grsecurity have provided for a decade on Linux.

Ah, so glad you people are finally ditching the UNIX design. Admittedly, it continues to stay in the stone age in many aspects. TTY.. lol. Talk about stone age. Heh.

Including the bash shell and now addressing the 260 character file path limit? Windows just got waaaaaay less annoying to use for developers employing package managers like Bower and NPM.

Not sure if it will bring defectors back into the Windows camp but it sure will be nice for enterprise developers that are forced to use Windows. Then again, enterprise won't standardize on Windows 10 for another five years or so.

According to Posix, the absolute largest this define can be is 256 (fortunately, Linux ignores this and goes for 4096).

Have you actually read that POSIX doc?

256 is the smallest acceptable value for PATH_MAX, not the largest.

PATH_MAX >= _POSIX_PATH_MAX >= 256

Most interfaces than return paths (eg. readlink(2), getcwd(3)) take a buffer and a length as arguments, and return an error if the buffer is too short, so most of the time you can allocate the buffers dynamically and completely ignore any system specific limits.

This is hilarious. I'm queer as fuck, but you know what's funny? I wouldn't even know what the term "micro-aggression" without y'all spreading it around. I love that anti-SJW advocates are disseminating the language they despise.

But seriously, can you do more of these? This is the perfect send-up.

WIndows 8 file explorer search just quietly stops when it hits a path/file over 260.
So searching for say *.dat and moving them might not get them all and then delete the structure and you are out of luck.

You'd hope they know not to. Windows developers really should know by now (It's only been 2 decades) that you need WCHAR path[MAX_PATH].

Also, you wouldn't get buffer overflows. The WIn32 API consistently uses explicit sizes on output buffers. E.g. GetCurrentDirectory(DWORD bufferlen, LPTSTR buffer) - the OS would recognize that your old program passed 260 for bufferlen. This change is more about SetCurrentDirectory, which is currently documented to accept nul-terminated strings up to MAX_PATH length.

It's not just third-party code. Win32 has APIs like this - note the MAX_PATH sized member of the struct.

Which "old API" is that that programs "should have stopped using years ago", exactly?

As for npm, it can handle long path names just fine (it uses \\?\ paths to achieve that). The problem, rather, is that most other things in Windows land couldn't handle those paths. So npm would create a directory tree that Windows Explorer couldn't delete, for example.

I suggest to use Long Path Tool Program if u have problems with path too long .

I suggest you to use Long Path Tool Program it will solve the problems of path too long.

I am getting this same issue, i guess the best thing to do is to use a third party app like Long Path Tool. Just download it and use it to solve this issue. I hope this would help.

Slashdot Mirror

Microsoft Removes 260-Character Path Length Limit In Windows 10 Redstone (softpedia.com)

260 comments