Update fails with long file name

[Adrian Buehlmann]

On 2015-09-29 00:35, Benjamin Fritz wrote:
> 
> 
> On Mon, Sep 28, 2015 at 5:24 PM, Matt Mackall <mpm at selenic.com
> <mailto:mpm at selenic.com>> wrote:
>>
>> On Mon, 2015-09-28 at 16:18 -0500, Benjamin Fritz wrote:
>> > I'm not sure whether the problem is in Mercurial, or in hgsubversion, so
>> > please let me know if this is a bad place to report the issue.
>> >
>> > I cloned a SVN repository by creating a new (empty) hg repository, then
>> > enabling the hgsubversion extension, and doing "hg pull" with the
> URL of my
>> > SVN repository.
>> >
>> > I used TortoiseSVN for all of the above, so I don't have the exact
> command
>> > line.
>> >
>> > The pull worked fine but the update step failed as follows:
>> >
>> >
> E:\Project_Files\XXX-hg\Verification/XXX_config/Error_Config/XXXXXXXXX/XXXXXXXXXXXXXXXXXX0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678.csv
>>
>> Programs that use the standard C interfaces have this limitation in
>> Windows (including cmd.exe and friends). Mercurial intentionally remains
>> in this set so that it doesn't create problematic files that not all
>> programs (such as del!) can handle.
>>
>> We'll fix this after Windows itself (including its core utilities)
>> finally gets its act together.
>>
> 
> I'll take that as a "won't fix" then. Pity. I guess I'm stuck without
> Mercurial on yet another project :-(
> 
> Unless of course there is some magical workaround, maybe in hgsubversion
> or some other extension.

The "magical" workaround is not to update to revisions containing files
which are "illegal" (that is, have names which don't conform to the
Windows naming conventions [1]) when running on Windows.

The pity is Windows, not Mercurial.

As you have noticed, Mercurial can deal with such names in the
repository _history_ (that is, inside .hg), even on Windows (which was a
real PITA to implement...). This includes names which are longer than
MAX_PATH.

We just decided to refuse creating such illegal names (in the workspace)
until really basic tools like Windows Explorer are able to handle
"illegal files" themselves. For example, (silly) Windows Explorer on
Windows 7 (which is still in widespread use) can't even delete a file
named AUX. Apparently, this hasn't changed in Windows 10.

[1]
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx