Exceeding the windows API MAX_PATH limit

[Adrian Buehlmann]

On 2012-05-28 17:42, 0xC0000022L wrote:

I prefer seeing real names. Those are pretty timeless.

> Hi,
> 
> sorry for picking up on an older topic. Martin pointed me to this
> mailing list over at StackOverflow
> <http://stackoverflow.com/questions/10753991>.
> 
>> Even if you might be able to morph mercurial into using the long path
>> api variants of Windows, other tools - which includes explorer on
>> Windows 7 (!) [1] - won't be able to handle paths with lengths > 260 anyway.

[..]

> a.) there are alternative file managers that can handle path lengths
> above MAX_PATH fine and some of those do in fact implement shell
> extensions.

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.

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

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.

> So even for the shell extension part of TortoiseHg it would
> make sense. Besides, the shell extension has nothing to do but to use
> the respective Unicode APIs and pass on the paths.

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

[1] https://bitbucket.org/tortoisehg/shellext/changeset/89d79c88e999/raw/