Exceeding the windows API MAX_PATH limit

[0xC0000022L]

Apologies in case my email came across aggressive in any way.

I was attempting to share my knowledge and hopefully provide facts that
(at least from reading up in the thread) weren't on the table.

> For what purpose are those shell extensions? Shell extensions are
> extensions for Windows explorer, which by itself can't handle "long path
> API" paths by definition.
Not the file managers are shell extensions, but they are able to use the
shell extension mechanism that Windows Explorer also uses. And shells
are replaceable by definition, too.

There are more complete replacements than mere file managers, of course
(though that was a more thriving business before Vista than now).

> Also, "File open" dialogs in programs basically load the same component
> as Windows explorer uses, thus exhibiting the same limitations on file
> names (that's why the TortoiseHg shell extension dll might be loaded in
> other programs as well).
Indeed. Usually after right-clicking something when we consider a
context menu handler shell extension (such as in TortoiseHg).

> An "interesting" side effect of using the \\?\ API is also that the
> programs using that API will be able to create files with reserved names
> (e.g. 'AUX'), which Windows explorer won't be able to delete anymore.
This is one of the things I tried to express in my initial email: it is
_not_ enough to use the Unicode API (i.e. link against the W-functions
instead of the A-functions). One actually has to make the effort to use
the respective prefix to get the long path handling.

Learned something new there. I knew that SUA could for example create
path names that (normal) Win32 programs couldn't touch, such as file or
folder names with a trailing dot. It appears that the same can be done
using the prefix explicitly, too. A variation of what you point out for
the DOS reserved names.

> You obviously haven't taken notice, but that has already been done.
> 
> The TortoiseHg shell extension is internally using wide strings
> (std::wstring in C++) everywhere and the wide API functions, since July
> 2011 (patches contributed by Toshi MARUYAMA [1]).
I was only aware it handled Unicode names (more or less found that by
chance when I had used some Cyrillic mixed with other code pages after
converting a SVN repo), not that it handled long path names per-se.

Thanks for pointing it out.