On Wed, Dec 07, 2016 at 12:13:01PM -0500, Will Parsons wrote: > On Tuesday, 6 Dec 2016 5:46 PM -0500, bch wrote: > > I've got a collection of files who's apparently only change is the > > EXECUTABLE bit set, but after a commit, they're still showing up in "f > > chan"; I retried w/ a --sha1sum switch; still listed as changed > > (despite the new commit showing up in the "f timel"). touch(1) all the > > affected files to bump the timestamp, re-commit, STILL listed as > > changed (but an entry in the timeline for that commit is listed). > > > > Haven't dug further into whats going on, but it looks like an error, > > or at least non-intuitive. > > What kind of filesystem? Apparent dicrepancies in the executable bit > can show up if the filesystem doesn't support proper permissions. >
Also, might be slightly related. On windows (using binary from download page: mingw 32bit), the EXECUTABLE bit seems to be ignore on the checkout and even if the filesystem don't support permissions, "fossil change" doesn't see any mismatch on the EXEC bit. Probably because of those check: http://fossil-scm.org/index.html/artifact?ln=1550+1563&name=1913859177ca9012 http://fossil-scm.org/index.html/artifact?ln=249+256&name=0cd782064e70a543 This check if current architecture support executable bits, but *not* if the actual *filesystem* support it. Moreover, it use _WIN32. So if I produce a 64bit windows executable using mingw-w64 (from msys2: https://msys2.github.io/), _WIN32 is not defined and "fossil change" always report a bunch of UNEXEC/EXEC changes on NTFS or FAT filesystem. I don't know if it's related with your problem, but I think there's something to improve here, I'm not sure yet what is best way to handle this ? May be a new setting to ignore permission can be useful, which can be set differently on different checkout. Regards, -- Martin G. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
