I tried that in the AU: let's just say this is better than nothing. Well. Hm. Well, actually I'm not even sure about that;
First not only programs must opt-in (through a manifest) -- and that is quite natural given the way some existing Win32 functions are modified, but that won't be taken into effect unless the computer is also opt'ed in. That second condition both makes little sense, and is improperly documented (the doc tells us: a manifested app or the GPO option; while in reality this is: AND)
Once you've manifested your program correctly (mainly by extracting what is interesting from powershell.exe, like usual because MSDN is shitty and does not describe the procedure to create the manifest with enough details) and configured your install with the good GPO (home edition users: go to hell) you happily starts to try the good old SetCurrentDirectory without the 260 chars limit.
It fails.
2 hours latter you understand that it fails because the MAX_PATH LIMIT IS STILL THERE IF lpPathName DOES NOT END WITH A BACKSLASH ‘ß‘¬ð’€¬ð€þ¬ð€
You then take a look at CreateProcess and understand that there is just no way to bypass the MAX_PATH limit with it on some of its params.
So you stop trying to use that half-backed and poorly documented "feature". The MAX_PATH (=260) limit in Windows is not gone. Maybe it's 5% gone, but that insufficient as hell.
As I am sure you can imagine, untangling the long-path limitation throughout the OS code, throughout RTL libraries, 3rd party libraries, .NET Framework & CLR, Windows Shell, etc. is a detailed, time-consuming process.
This was never going to be "oh, just change this flag and ... BINGO".
Rest assured we've several teams throughout the company (including mine) currently digging into this long-path effort.
> A registry key allows you to enable or disable the new long path behavior. To enable long path behavior set the registry key at HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled (Type: REG_DWORD).
First not only programs must opt-in (through a manifest) -- and that is quite natural given the way some existing Win32 functions are modified, but that won't be taken into effect unless the computer is also opt'ed in. That second condition both makes little sense, and is improperly documented (the doc tells us: a manifested app or the GPO option; while in reality this is: AND)
Then a single example so that you can understand the new "quality" of what MS is shipping: SetCurrentDirectory() https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
Once you've manifested your program correctly (mainly by extracting what is interesting from powershell.exe, like usual because MSDN is shitty and does not describe the procedure to create the manifest with enough details) and configured your install with the good GPO (home edition users: go to hell) you happily starts to try the good old SetCurrentDirectory without the 260 chars limit.
It fails.
2 hours latter you understand that it fails because the MAX_PATH LIMIT IS STILL THERE IF lpPathName DOES NOT END WITH A BACKSLASH ‘ß‘¬ð’€¬ð€þ¬ð€
You then take a look at CreateProcess and understand that there is just no way to bypass the MAX_PATH limit with it on some of its params.
So you stop trying to use that half-backed and poorly documented "feature". The MAX_PATH (=260) limit in Windows is not gone. Maybe it's 5% gone, but that insufficient as hell.