Update fails with long file name

[Adrian Buehlmann]

On 2015-09-29 07: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.

It's not impractical. It would be impractical being blamed for creating
files, which even Windows Explorer can't delete any more.

Think of a user X calling support: "Help! I've cloned this repo from the
internet, now I even can't delete it any more!".

Your repository is not unusable. Just the revision(s) which contain file
names which violate the Windows naming conventions.

You could, for example, clone this repository to a Linux box, rename
that file to something which conforms to the Windows naming conventions,
commit that there, pull that revision to your Windows box and update to it.

As long as you don't update to any offending revisions, you can use that
repository perfectly fine on Windows. This is includes creating clones,
exploring the history of the repo, etc.