Update fails with long file name

[Steve (Gadget) Barnes]

On 29/09/2015 06:52, Benjamin Fritz wrote:
> 
> On Sep 29, 2015 12:30 AM, "Adrian Buehlmann" <adrian at cadifra.com
> <mailto:adrian at cadifra.com>> wrote:
>>
>> 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>
>> > <mailto: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
> 
> Seeing as Subversion can handle this file just fine, your explanation
> may be completely correct but is also condescending, pedantic, and
> impractical. Mercurial *could* support such files. It chooses not to.
> And because hg update does not allow ignoring errors of any kind, this
> makes the entire repository unusable.
> 
> 
> 
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> https://selenic.com/mailman/listinfo/mercurial
> 

Have you actually tried doing a SVN clone, on Windows, of the repository
in question at a version where that file exists? I would lay odds that
a) it will fail & b) the file was created and checked in from a Linux
system where the maximums for most file systems are 255 characters in a
file name and 4096 in a path as opposed to the windows limit of 260 for
the whole path, including drive letter, colon and a concluding 0x00
byte.  Possibly worse still the Windows API for file handling allows
paths that are illegal for all the Windows tools by using \\?\ prefix,
see
https://msdn.microsoft.com/en-gb/library/windows/desktop/aa365247%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
for details.

Since the offending file WILL cause problems in a large number of
windows tools can I suggest contacting the SVN administrator on the
system that it is coming from to request that the file be renamed or
removed both in the current version if it exists and in the SVN history
via the SVN dump/filter/import process.

If the offending file does not exist in the current SVN repository,
again quite likely, but only in the history you can still consider using
hg without the SVN admin but with a partial history by cloning starting
from the revision that removed the offending file.
-- 
Steve (Gadget) Barnes
Any opinions in this message are my personal opinions and do not reflect
those of my employer.