Windows 10 explorer + Long Pathnames = Misery. 2

[hairlessupportmonkey]

Howdy,

We have a customer (some may know this type - architecture / Cadd designers) and they insist on using deep paths and long file names for organising their work.

Since the latest incarnation of Windows 10, these long pathnames will crash explorer under the following conditions.

1) Drag and Drop from long path to somewhere else.
2) using explorer to search within long paths.

I have been googling like crazy, and yes there are options to "enable long name" support in windows 10, but thats really only to enable support in w32 applications.

I found a couple of posts suggesting a couple of KB's, but they arent installed on the machine(s)

and stuff like:

http://superuser.com/questions/1114572/windows-10-ver-1607-file-explorer-long-paths-not-working

I would rather not use a third party app if possible.

Any clues?


ACSS - SME
General Geek

 

[strongm]

Pathnames longer than 260 characters have been anathema to Explorer (and other parts of Windows) for years, even though the underlying NTFS can happily deal with paths of over 32000 characters. I'm not sure I noticed Microsoft announcing that Windows 10 Explorer has official support for anything longer than 260 characters. As yet.

 

[hairlessupportmonkey]

Agree. However, more to the point, explorer, rather than chucking up an error, simply closes down and completely relaunches. Apparently this behaviour was fixed with windows 7 back in 2013 where you could still browser, search and even copy and paste without explorer completely crashing.

ACSS - SME
General Geek

 

[hairlessupportmonkey]

Well MS have lifted the 260 character limit.

https://mspoweruser.com/ntfs-260-character-windows-10/

However I may have found the answer:

https://social.technet.microsoft.co...y-a-long-network-path?forum=win10itprogeneral

ACSS - SME
General Geek

 

[strongm]

>Well MS have lifted the 260 character limit.

Actually, no, they haven't. The setting in question - already referred to in the link from your first post - does not really lift any limits whatsoever. What it does is tell applications that internally already know how to use the NTFS path size (i.e. that are using the appropriate Unicode versions of the API calls) to enable that functionality (or, more accurately, to remove the filter running at the Windows API level that enforces the 260 character limit before paths are passed to the underlying API calls). Applications that are not using appropriate APIs will not suddenly start using them because of this setting, and will remain limited to 260 chars. The Unicode versions are basically file i/o API calls that honour the "\\?\" prefix to allow extended-length Unicode paths to be passed; the manifest (or the registry setting) just means you don't have to use the prefix to get to that functionality.

Unfortunately, for now Windows Explorer still uses API calls that cannot use extended-length paths. However, as youi say, the crashing is new behaviour in Anniversary edition. Looks to me as if a buffer check has gone awol, and that an extended-length path (that explorer doesn't know how to deal with) is being returned to a function call that is only expecting a maximum of 260 characters, which in turn causes an attempt to write data to an unexpected location, and thus a crash.

These are the functions that no longer have MAX_PATH restrictions if you opt-in to long path behavior: CreateDirectoryW, CreateDirectoryExW GetCurrentDirectoryW RemoveDirectoryW SetCurrentDirectoryW, CopyFileW, CopyFile2, CopyFileExW, CreateFileW, CreateFile2, CreateHardLinkW, CreateSymbolicLinkW, DeleteFileW, FindFirstFileW, FindFirstFileExW, FindNextFileW, GetFileAttributesW, GetFileAttributesExW, SetFileAttributesW, GetFullPathNameW, GetLongPathNameW, MoveFileW, MoveFileExW, MoveFileWithProgressW, ReplaceFileW, SearchPathW, FindFirstFileNameW, FindNextFileNameW, FindFirstStreamW, FindNextStreamW, GetCompressedFileSizeW, GetFinalPathNameByHandleW.

 

[hairlessupportmonkey]

Cheers, thanks for your great indepth answer!

ACSS - SME
General Geek

 

[pmonett]

@strongm:

I understand what you say about the first article and I do believe that you are perfectly right when you explain about API calls that are not going to change, but when I read the article - and especially the line that says "Microsoft is giving users the ability to increase the limit" - I am not surprised that most people interpret that as "MS have lifted the 260 character limit". Without your correction, I would have thought the same.

Just goes to show that writing for the general public requires a bit more work than just proofreading and grammar correction.

I've got nothing to hide, and I demand that you justify what right you have to ask.