MAX_PATH limitation is going away

[Sektor]

MAX_PATH is going away in Windows 10.
You can read about it here, here and here.
Will TC honor it?

[Horst.Epp]

From the help about wincmd.ini settings:
LongNameCopy=0
During file operations, warn if target name is longer than 259 characters:
0=always
1=never
2=if source name isn't longer than 259 characters
3=disallow long names

[Dalai]

Even without any additional settings TC is able to browse paths longer than MAX_PATH and copy files to/from them. In case of copying/moving files it will ask, as Horst pointed out.

Regards
Dalai

[milo1012]

2Sektor
The links you provided only talk about .Net, which will wrap the Win API calls anyway.
Most other programs written in a language that interact with the API directly (more or less), like in C/C++/VB/Delphi, will most likely use the Windows headers, and these still define MAX_PATH as 260.
As TC isn't using .Net, these change won't affect it at all (but maybe some plugins written in a .Net language, but there are only a few of them).

And as already pointed out, TC is able to use path lengths > MAX_PATH in nearly all cases.

[MVV]

This new capability is enabled for applications that target the .NET Framework 4.6.2 (or later).

Well, this is only related to .NET (which hasn't supported long paths w/o third-party libraries earlier).

The key File and Directory Management APIs respect this and now allow you to skip the check for MAX_PATH without having to resort to using “\\?\” (look back to my earlier posts on path formats to understand how this works).
...

Code: Select all

<longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware>

This seems to be related to native applications too, but TC already supports long paths via mentioned prefix \\?\ so there is nothing that may be improved. But most plugins do not support long paths and may have e.g. fixed-size buffers so it is a bad idea to pass such paths to them.

[umbra]

2milo1012,MVV
Actually, it's a system-wide setting. For now, it will be disabled by default - it has to be enabled in GroupPolicy and opt-in to in application's manifest. .Net is just taking advantage of it.

TC is able to use path lengths > MAX_PATH in nearly all cases.

I'd say that's the point here. Inconsistent behavior can be unpleasantly surprising. There have been several bugs reported in TC because of this.

[MVV]

I've just edited my answer when I've read second article... anyway there is no need to change anything in TC.

BTW I don't think this feature of Windows 10 will be usable because no one will write applications just for W10 w/o supporting Windows 7 where prefix \\?\ is still required. M$ doesn't know how to attract people to their dumb new OS and invent such a strange things.

[milo1012]

This seems to be related to native applications too

...

Actually, it's a system-wide setting.

It doesn't matter. When I compile a program or DLL in C/C++ and many other languages, I use the Windows headers. These headers define MAX_PATH to 260.
So the program will have the limit set by compile time, no matter what you do in the OS later on. There is no advantage with this setting for now, except that you now *may* pass long paths to API functions w/o the infamous \\?\ prefix, but you have no guarantee for it.

So to make this have the advantage that some people think it will provide, we'd need:

• wait until the Windows headers (in Visual Studio, or the DDK, or the Platform SDK or whatever) is properly updated, i.e. the runtime libs may take advantage of it
• wait until MS forces this setting to be enabled all the time, otherwise it's useless when it stays optional
• not checking any more for the target OS in the application, assuming Win 10 with the mentioned update

The latter will only be the case when an app can't target an Windows version below 10. So all in all it will take years until we get the advantage for standalone applications, and for TC these things don't matter for now anyway.

[umbra]

2MVV
Considering, that getting rid of MAX_PATH is one of the most requested features ever (just check UserVoice and other sites allowing voting for MS features), I wouldn't say it's DOA. Let's wait if it gets any traction. There is plenty of time until it gets enabled by default.

<offtopic>
And regarding Win10 itself - while I agree some aspects of its UI are questionable, its backend improvements are more than worth it. But I'm not running around and praising/bashing it on every chance.

[milo1012]

...I wouldn't say it's DOA. Let's wait if it gets any traction. There is plenty of time until it gets enabled by default.

Is there any source which states that it *will* be enabled by default one day?
There was already some discussion when MS installed some ability to make Windows case sensitive, but I haven't seen MS forcing it.
And even if MS would flip the switch one day with another update: developers still have to check for the OS version/update running, so that they still need to use both API flavors for another couple of years.

BTW, a lot of API functions use data structures with an array of MAX_PATH characters.
So as a developer I'd still need to limit myself to MAX_PATH internally, no matter how long a path I may use for default file handling API functions.

[MVV]

It doesn't matter. When I compile a program or DLL in C/C++ and many other languages, I use the Windows headers. These headers define MAX_PATH to 260.
So the program will have the limit set by compile time, no matter what you do in the OS later on.

Compile-time constants do not affect Windows-side API so if you do not use these constants, all should be fine.

There is no advantage with this setting for now, except that you now *may* pass long paths to API functions w/o the infamous \\?\ prefix, but you have no guarantee for it.

That's true, and I've mentioned this too. It is a quite specific and rare setting to be able to count on it.

BTW, a lot of API functions use data structures with an array of MAX_PATH characters.
So as a developer I'd still need to limit myself to MAX_PATH internally, no matter how long a path I may use for default file handling API functions.

Unicode API functions support long paths for years so it is not a problem (these functions disable checks if you use \\?\ prefix).

Considering, that getting rid of MAX_PATH is one of the most requested features ever

I agree that this limitation made just for backward compatibility in such form is stupid (M$ could e.g. add an API for disabling limitation for current process). Another similar stupid example is X64 redirection and keeping 64-bit files in System32 folder. Unfortunately the more applications live with it, the more difficult it is to change such things...

[umbra]

2milo1012
I said "enable by default", not "force". The group policy setting is just for now, while the feature is still in development. The long-term plan is that applications have to opt-in using their manifest, as I have already written. Metro apps will have it enabled automatically.

They still plan to do some more changes in path handling, so maybe they will revisit the case (in)sensitivity as well. But there hasn't been any official statement about that.

BTW, according to MSDN (https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx):

These are the directory management functions that no longer have MAX_PATH restrictions if you opt-in to long path behavior: CreateDirectoryW, CreateDirectoryExW GetCurrentDirectoryW RemoveDirectoryW SetCurrentDirectoryW.

These are the file management functions that no longer have MAX_PATH restrictions if you opt-in to long path behavior: 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.

[milo1012]

Compile-time constants do not affect Windows-side API so if you do not use these constants, all should be fine.

It's not just your own code, all runtime libs are affected by this too, as they need to assume the old limit (I've seen a lot of runtime lib constraints due to this). So like I said: we need to wait for an updated SDK at least, but which will only be of use if MS forces the setting someday.

BTW, according to MSDN (https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx)

Thanks for the link.
Seems we're still having the limit for most shlwapi API functions (e.g. PathFindFileName, SHGetFileInfo).

The long-term plan is that applications have to opt-in using their manifest, as I have already written. Metro apps will have it enabled automatically.

Sure, but optional is optional. So you either request it and don't support anything else, or you need both code paths; that's the point I don't get with this approach. The WIN32 API didn't really get any improvement over the years. MS had some chances, like e.g. dropping the ANSI API with native x64 ("Win64"), but they didn't. So now we end up with a manifest mess instead of a real improvement, like a new set of file handling functions.

Anyway, let's see what happens in the next years.

[Lefteous]

For me the question is if there is any chance to benefit for Windows 10 users when it comes to shell functions. While the normal file management functions used by TC already supported very long paths since a while many shell functions did not.