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

[Yuya Nishihara]

On Mon, 17 Oct 2016 14:41:53 +0200, Mads Kiilerich wrote:
> 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.

Please correct me if I misread the patch.

 1. checkexec() on normal unix filesystem: creates 'checkisexec' 0755
 2. copy it to VFAT: 'checkisexec' 0644
 3. copy back from VFAT: 'checkisexec' 0644
 4. checkexec() returns False because no exec flag set