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

Yuya Nishihara yuya at tcha.org
Sun Oct 16 14:19:30 UTC 2016


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.



More information about the Mercurial mailing list