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 _______________________________________________ Mercurial-devel mailing list Mercurialemail@example.com https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel