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

An anonymous reader quotes a report from Softpedia: Windows 10 build 14352, a preview version of the upcoming Anniversary Update (also known as Redstone), comes with an eagerly awaited change that Microsoft hasn't yet announced publicly. The 260-character path length limit in Windows can be removed with the help of a new policy, thus allowing you to run operations with files regardless of their path or file name. While this new rule is not enabled by default, admins can turn it on by following these instructions. Launch the Registry Editor by clicking the Start menu and typing "regedit.exe," and then navigate to the following path: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy Objects\{48981759-12F2-42A6-A048-028B3973495F}Machine\System\CurrentControlSet\Policies. Look for an entry called "LongPathsEnabled," and if it does not exist, simply right-click Policies, select New DWORD (32-bit), name it "LongPathsEnabled" (without the quotes), enter value 1, and you're good to go. The description of the preview reads, "Enabling NTFS long paths will allow manifested win32 applications and Windows Store applications to access paths beyond the normal 260 char limit per node. Enabling this setting will cause the long paths to be accessible within the process." While the Windows 10 preview build 1452 has been made available last week, according to Windows Central, a Microsoft team member says that the company could released Windows 10 Mobile build 14352 for Insiders on Tuesday, May 31.

Comments

"simply right click"

[Anonymous Coward]

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

Re: "simply right click"

[ArmoredDragon]

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.

Re:"simply right click"

[Gadget_Guy]

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.

Re:"simply right click"

[Anonymous Coward]

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

Re:"simply right click"

[meerling]

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.

Re: "simply right click"

[Dutch Gun]

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.

Re:"simply right click"

[Mats Svensson]

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

Re: "simply right click"

[WinstonWolfIT]

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

Re: "simply right click"

[SuricouRaven]

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

Re:"simply right click"

[jandersen]

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.

Re:"simply right click"

[geekmux]

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

Re: "simply right click"

[Athanasius]

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.

Re:"simply right click"

[fuzzywig]

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.

Re: "simply right click"

[dbIII]

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.

Re:"simply right click"

[EvilSS]

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.

Re:"simply right click"

[EvilSS]

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.

Re: "simply right click"

[zifn4b]

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.

Re:"simply right click"

[Anonymous Coward]

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

Re: "simply right click"

[pla]

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.

Re: "simply right click"

[Athanasius]

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.

Re: "simply right click"

[ComputerGeek01]

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.

Re:"simply right click"

[squiggleslash]

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

Re:"simply right click"

[Anonymous Coward]

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.

Re: "simply right click"

[chuckugly]

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.

Re:"simply right click"

[EvilSS]

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

Re:"simply right click"

[Anonymous Coward]

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.

Re: "simply right click"

[operagost]

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.

Re:"simply right click"

[Drumhellar]

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

Re: "simply right click"

[jbengt]

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.

Re: "simply right click"

[TemporalBeing]

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.

Re:"simply right click"

[TemporalBeing]

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.

Re: "simply right click"

[ModernGeek]

Remember C:\PROGRA~1\ ??

Re: "simply right click"

[Dutch Gun]

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.

Re: "simply right click"

[Big Hairy Ian]

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

Re: "simply right click"

[shutdown -p now]

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.

Re: "simply right click"

[chuckugly]

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.

Re: "simply right click"

[RockDoctor]

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.

Finally

[fustakrakich]

I can replace my Linux machine!

Re:Finally

[ChunderDownunder]

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

Re:Finally

[bloodhawk]

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.

Re:Finally

[l3v1]

Innovation? Really?

Re:Finally

[NotAPK]

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.

Re:Finally

[AmiMoJo]

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.

Re:Finally

[fibonacci8]

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

Re:Finally

[queBurro]

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.

Re:Finally

[RatherBeAnonymous]

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.

Re:Finally

[Anonymous Coward]

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.

Re:Finally

[RatherBeAnonymous]

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.

Re:Finally

[Zocalo]

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.

Re:Finally

[cdrudge]

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.

Re:Finally

[RatherBeAnonymous]

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.

Re:Finally

[Waccoon]

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"

Re:Finally

[squiggleslash]

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

Re:Finally

[David_Hart]

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.

Re:Finally

[AmiMoJo]

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.

Re:Finally

[AmiMoJo]

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.

Re:Finally

[Gazzonyx]

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.

Re:Finally

[chuckugly]

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.

Re:Finally

[fustakrakich]

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.

Re:Finally

[fustakrakich]

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

Re:Finally

[cdrudge]

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

Re:Finally

[MightyYar]

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.

Re:Finally

[shutdown -p now]

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

Re:Finally

[shutdown -p now]

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.

Does that mean...

[__aaclcg7560]

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

Re:Does that mean...

[R33P]

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

Dear Microsoft,

[Anonymous Coward]

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.

Re: Dear Microsoft,

[Anonymous Coward]

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

Re: Dear Microsoft,

[meerling]

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

Re:Dear Microsoft,

[geekmux]

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

Re:Dear Microsoft,

[jones_supa]

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.

Re:Dear Microsoft,

[DoofusOfDeath]

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?

Re:Dear Microsoft,

[SirSlud]

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)

Legacy Application Support?

[Anonymous Coward]

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.

Re:Legacy Application Support?

[Gravis Zero]

easy fix: just recompile.

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

Re:Legacy Application Support?

[Fragnet]

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

Re:Legacy Application Support?

[0ld_d0g]

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?

Re:Legacy Application Support?

[Gravis Zero]

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!

Re:Legacy Application Support?

[0ld_d0g]

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.

Re:Legacy Application Support?

[Gravis Zero]

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.

Re:Legacy Application Support?

[0ld_d0g]

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.

Re:Legacy Application Support?

[Gravis Zero]

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.

Re:Legacy Application Support?

[spitzak]

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.

Re:Legacy Application Support?

[Mr. Sketch]

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.

Re:Legacy Application Support?

[shutdown -p now]

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

Re:Legacy Application Support?

[shutdown -p now]

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.

Re:Too soft

[chipschap]

Microsoft managers train with the airlines.

Re: Unicode and \\?

[Rosyna]

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

Comment removed

[account_deleted]

Comment removed based on user account deletion

There's a good reason it's not on by default

[PhrostyMcByte]

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.

Re:There's a good reason it's not on by default

[PhrostyMcByte]

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.

Re: There's a good reason it's not on by default

[ljw1004]

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

Re:There's a good reason it's not on by default

[wwalker]

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?!

Re:There's a good reason it's not on by default

[t0y]

MAX_PATH includes the null terminator.

Re:There's a good reason it's not on by default

[DarkOx]

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.

Thanks

[hcs_$reboot]

But no thanks ; not using OSes that have registries.

Re:Thanks

[arth1]

But no thanks ; not using OSes that have registries.

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

Re:Thanks

[freeze128]

So... OS/2 is fine?

Re:Thanks

[hcs_$reboot]

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

Re:Thanks

[F.Ultra]

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

Re:Thanks

[butzwonker]

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

[kriston]

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.

Great

[Anonymous Coward]

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.

Why are people excited about this?

[Improv]

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

Re:Why are people excited about this?

[quenda]

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

Re:Why are people excited about this?

[Ramze]

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.

Re:Why are people excited about this?

[Improv]

Oh. Whoops. Fair point.

Re:Why are people excited about this?

[jeremyp]

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

Re:Why are people excited about this?

[Malc]

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.

Re: Why are people excited about this?

[Dr_Barnowl]

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.

Re:Why are people excited about this?

[dotgain]

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?

Re: Why are people excited about this?

[Dr_Barnowl]

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

Re:Why are people excited about this?

[Improv]

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.

Netware

[Anonymous Coward]

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

Re:Login is hard to understand

[hcs_$reboot]

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.

Re:Removable drives ... oh well

[Tablizer]

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.

There's no good reason it's not on by default

[johannesg]

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.

Re:There's no good reason it's not on by default

[OneSmartFellow]

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

Yet another reason to hate Java

Re:There's no good reason it's not on by default

[DarkOx]

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.

Re:There's no good reason it's not on by default

[johannesg]

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.

I hit this limit once in the Unix world

[Michael Woodhams]

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

Re:Let's welcome Windows out of the stone age

[jeremyp]

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.

\\?\ Solved this...

[Macfox]

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.

Re:\\?\ Solved this...

[brantondaveperson]

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.

Re: \\?\ Solved this...

[Macfox]

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

Re:So, that's why they bought Mojang.

[brantondaveperson]

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

Re:This is not an NTFS problem but an old API prob

[brantondaveperson]

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

Re:Login is hard to understand

[brantondaveperson]

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.

Re:Oh great, another "Make it work" registry value

[brantondaveperson]

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

Maybe they can now fix all the illegal characters

[simpz]

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.

Re:Oh great, another "Make it work" registry value

[complete loony]

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

Re:Let's welcome Windows out of the stone age

[armanox]

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

yay, how about resizable windows next??

[ealbers]

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!

Re:Oh great, another "Make it work" registry value

[brantondaveperson]

No.

Re:Login is hard to understand

[twdorris]

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.

Re:Login is hard to understand

[DarkOx]

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.

Re:They really are getting desperate

[dotgain]

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!

Welcome to 1990

[MoarSauce123]

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?

Re:Welcome to 1990

[RatherBeAnonymous]

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.

Registry path in summary is wrong

[sydbarrett74]

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.

Re:Login is hard to understand

[fibonacci8]

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

Re:Login is hard to understand

[hcs_$reboot]

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

Re:Login is hard to understand

[hcs_$reboot]

Undefined behavior, indeed.

Re:Removable drives ... oh well

[dbIII]

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.

260 bytes should be enough for every one

[140Mandak262Jamuna]

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.

Paramteric had a clever solution!

[140Mandak262Jamuna]

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.

Re:Paramteric had a clever solution!

[140Mandak262Jamuna]

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.

Re:Login is hard to understand

[DoofusOfDeath]

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.

Re:Oh great, another "Make it work" registry value

[ArchieBunker]

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

How many years of using robocopy to delete?

[Culture20]

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

Re:This is not an NTFS problem but an old API prob

[The-Ixian]

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.

That's the MINIMUMS section

[raymorris]

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.

Re: Finally... So directory can be called

[LinuxIsGarbage]

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>

String parsing is very time consuming

[DidgetMaster]

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.

Re:Let's welcome Windows out of the stone age

[raymorris]

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.

Windows 260-character path length can be removed

[tetraverse]

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

Deutsch Dateinamenskonvention

[karlandtanya]

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!

Re:Removable drives ... oh well

[Tablizer]

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.

Courting frontend devs perhaps?

[wazzzup]

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.

Re:Let's welcome Windows out of the stone age

[Anonymuous Coward]

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.

Re:Unicode and \\?

[TemporalBeing]

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.

Re:Login is hard to understand

[shutdown -p now]

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

Re:This is not an NTFS problem but an old API prob

[shutdown -p now]

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.

Re:Removable drives ... oh well

[dbIII]

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.

Microsoft Removes 260-Character Path Length Limit

[Svetlanaa]

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