[PATCH 6 of 6 v2] paths: allow util.finddirs touse os.path.sep

[Adrian Buehlmann]

On 2017-09-21 06:37, Matt Harbison wrote:
> 
> On Sep 20, 2017, at 12:46 PM, Augie Fackler <raf at durin42.com
> <mailto:raf at durin42.com>> wrote:
> 
>> On Tue, Sep 19, 2017 at 09:57:50AM -0700, Kostia Balytskyi wrote:
>>> # HG changeset patch
>>> # User Kostia Balytskyi <ikostia at fb.com <mailto:ikostia at fb.com>>
>>> # Date 1505837708 25200
>>> #      Tue Sep 19 09:15:08 2017 -0700
>>> # Node ID 0a561e2299b6880dd0e6e91294c92bbc0aef726b
>>> # Parent  29007a29700f107b7fd5bf139fa192f9528d6349
>>> paths: allow util.finddirs touse os.path.sep
>>
>> This all sounds necessary, but I lack the required Windows
>> understanding to know if it's a good idea to do it this specific way.
>>
>> I've added our resident Windows experts to see what they think. The
>> patches themselves look reasonably straightforward, and you can
>> probably give a thumbs-up or thumbs-down on the basis of the approach
>> outlined in patch 1.
> 
> I didn't get a chance to really look at this yet.  I've never used long
> paths myself, so IDK if I'll have any insight.  I do remember mpm not
> liking this for interoperability reasons [1].  I'm not sure if that
> situation has improved since then.  (I assume that we don't care about
> XP and Vista anymore.)  If it hasn't, do we need to do something like
> use long paths, but abort before creating a file that exceeds MAX_PATH
> unless some config item is enabled?  That seems nasty, but I'm not sure
> what else to do.
> 
> Alternately, I just found an article that they may have lifted the
> restriction on Windows 10, if you opt in.  I'm too tired to digest this
> now, but here it is:
> 
> https://msdn.microsoft.com/en-us/library/aa365247(v=vs.85).aspx#maxpath
> 
> 
> If we can enable this by editing the manifest, it's probably cleaner
> than adding more Windows hacks.
> 
> 
> [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2012-April/039382.html

The thing is that lots of tools on Windows traditionally could not
handle files created using the "long path" API.

With this API (as I remember), you can create files with filenames that
Windows explorer couldn't even delete anymore. Those names don't even
need to be long. Some special file names are sufficient in order to keep
explorer from being able to delete them (I would have to dig out
examples again).

I don't know if explorer of e.g. Windows 10 still has this problem
(right now I'm not that interested to check again).

Other tools might have problems too. Think of backup tools.

On the other hand, this "only" affects files in the working directory
(the store file names are carefully encoded) and Mercurial itself should
then at least be able to delete such files, using - for example -
commands like "hg update null". You would then of course need a hg
version which is recent enough (i.e. includes the new "long path" API
calls).

Another mitigating factor (IMHO) is, that Mercurial has become quite a
niche tool on Windows. I think git has largely won the race on Windows.
So, folks who still use Mercurial on Windows are likely rather expert
users which are likely more supposed to know what they do.

Perhaps, it would be sufficient to have some warnings when users try to
add problematic file names (I think we already have some warnings in place).

So, maybe this could be implemented by default-disabling it with some
new config knob, which expert users - who are willing to deal with the
consequences - then can enable.

I once hacked a small tool for getting rid of trees containing such
files: https://bitbucket.org/abuehl/winrm/src . I used that for getting
rid of trees containing files with nasty names used for testing.