Exceeding the windows API MAX_PATH limit

Matt Mackall mpm at selenic.com
Fri Apr 20 15:45:12 CDT 2012


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?

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.

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


-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list