Update fails with long file name

[Matt Mackall]

On Tue, 2015-09-29 at 00:52 -0500, Benjamin Fritz wrote:
> On Sep 29, 2015 12:30 AM, "Adrian Buehlmann" <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>> 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.

Yes, this is exactly right. We know how to fix it. But it is our
judgment that the Windows ecosystem is not ready for the fix. You may
disagree, but you're also not tasked with supporting all our Windows
users. SVN indeed took a different approach, but it has a different
notion of "good idea" than us.

If you're ambitious, you could write a small extension to fix it for
yourself. Use the win32mbcs extension as a starting point and hack it to
use "\\?\" prefixes everywhere to get extended length paths:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%
28v=vs.85%29.aspx#maxpath

I don't have a Windows machine and no Windows user has cared enough to
spend an afternoon doing this so the job falls to you, the person who's
complained the loudest in 10 years.

-- 
Mathematics is the supreme nostalgia of our time.