disrstate._check(link|exec) modifies repo dir mtime

[Mads Kiilerich]

On 10/16/2016 04:19 PM, Yuya Nishihara wrote on the users list:
> On Sun, 16 Oct 2016 14:08:52 +0200, Mads Kiilerich wrote:
>> On 10/16/2016 12:29 PM, Yuya Nishihara wrote:
>>> On Sat, 1 Oct 2016 11:35:40 -0700, Dorian Taylor wrote:
>>>> is there a reason why all this testing can’t go on in $REPO/.hg?
>>> No idea why, but there was an attempt to move check* files to .hg/cache.
>>>
>>> https://www.mercurial-scm.org/pipermail/mercurial-devel/2015-October/074885.html
>>> https://www.mercurial-scm.org/pipermail/mercurial-devel/2015-November/074971.html
>> About that:
>>> I don't think this is sufficient. This case can occur, for instance, if
>>> someone naively copies a repo from one machine to another with a USB
>>> stick. Or perhaps they've done a naive recursive chmod. Then we're
>>> permanently stuck thinking our filesystem doesn't have exec bits. If
>>> our fast-path files don't have the right permissions (for who knows
>>> what reasons), then we have to do the entire slow path.
>> I don't see how copying or chmod can trigger wrong measurement of file
>> system capabilities. "Wrong" files will be removed again - just like in
>> the old slow path. The slow path will pretty much be the existing slow
>> path - it will not be slower than before but it will usually not be used.
> Can we distinguish "no exec bit support" with "cache/checkisexec was chmod
> by user" ? If a repository is copied through VFAT USB stick, exec bit could
> be dropped from both checkisexec and checknoexec.


The basic idea (IIRC) in 
https://www.mercurial-scm.org/pipermail/mercurial-devel/2015-October/074887.html 
is that if we have one cached file that is exec and another that isn't, 
then we can be pretty sure that that file system supports X bit. (That 
assumption might be wrong for filesystems that cache the x bit but 
doesn't persist it - but in that case the repo will be screwed anyway.)

If we can't conclude anything from stat'ing existing files, we remove 
them and check the old way ... and if the result is positive, we leave 
the files behind so it can take the fast path next time.

I thus don't see what you are asking for that not already is taken care of.

/Mads