Exceeding the windows API MAX_PATH limit

[Angel Ezquerra]

On Fri, Apr 20, 2012 at 10:45 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Fri, 2012-04-20 at 22:06 +0200, Angel Ezquerra wrote:
>> On Apr 20, 2012 8:33 PM, "Matt Mackall" <mpm at selenic.com> wrote:
>> >
>> > On Fri, 2012-04-20 at 14:14 +0200, Noel Grandin wrote:
>> > >
>> > > On 2012-04-20 14:04, Adrian Buehlmann wrote:
>> > > > So I'd recommend to make sure that *all* your other tools can handle
>> > > > long paths _first_ before proposing to change mercurial's working copy
>> > > > handling on Windows to use the long path api's.
>> > >
>> > > The point is that these kinds of problems ARE popping up, and we (being
>> > > the users) don't need ALL of our tools to support long paths.
>> >
>> > This is not even remotely worth the trouble on our end, where we'll have
>> > to handle bug reports like "I can't delete this file Mercurial created
>> > without reinstalling Windows, you guys suck!"
>> >
>> > Ask again when at least Explorer can handle these paths.
>>
>> I think you are right. However I think that mercurial's error message could
>> be better on this case. A little example:
>>
>> c:\>mkdir short
>> c:\>cd short
>> c:\short>hg init
>> c:\short>echo 1 >
>> dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd.txt
>> c:\short>hg add
>> dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd.txt
>> c:\short>hg commit -m "long file added"
>> c:\short>cd ..
>> c:\>hg clone short a_longer_clone_name
>> updating to branch default
>> abort:
>> c:\a_longer_clone_name\dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd.txt:
>> The system cannot find the path specified
>>
>> "The system cannot find the path specified" is unclear error message IMHO.
>> I know that is the message that windows gives when you try to handle a file
>> with a long filename, but I think mercurial could give a better error
>> message. For example:
>>
>> abort:
>> c:\a_longer_clone_name\dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd.txt:
>> The file name exceeds windows' max filename length of 255 characters
>
> So.. your proposal is that we should take the error number (ie 2) that
> Windows gives back and then guess why it happened from the large
> possible space of reasons, via what's effectively a mini expert system?

But at some level mercurial must already be translating some of the
errors it encounters to make them understandable by the user, isn't
it? There is a wide range between showing raw error numbers and
creating an expert system...

> I don't consider that sort of thing to be good engineering practice.
> First, it's directing effort to the wrong place: once such an error has
> occurred, you've already lost. Second: you are liable to get your
> diagnostic wrong, at which point you've probably stymied diagnosis by
> humans.

If mercurial tries to open a file for writing and it fails because the
file is too long, is it helpful to tell the user "cannot find the path
specified", even if that is what windows reports? Does it help the
human in diagnosing the problem? I think it doesn't. I think it is
misleading and could make it hard to diagnose the problem.

I wonder what can be done in this case to address the problem before
it happens? The error only happens depending on the depth of the
folder you are cloning to. This means that you can only catch it when
it is too late, doesn't it? Perhaps mercurial could, on windows, warn
when adding files with names longer than a safe threshold?

> And for what it's worth, I actually see this error object:
>
> WindowsError(206, 'File name is too long')
>
> ..which results in
>
> abort: C:\long-stupid-target
> \aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa: File name is too long

That's weird. The example I showed was taken right from my Windows 7
command line terminal. I just ran it again and I got the same error.

Angel