(Why yes, I am doing something moderately evil with Fossil...) I have found a rather unpleasant-looking bug where if a file's content changes too quickly, and its size does not change, it's not considered to have changed. It smells as if Fossil is using a combination of the file length and timestamp to determine whether the file has changed.
Test case follows:
echo "Test data" > file
fossil add file
fossil commit file -m "Ancestor" # succeeds
echo "Branch 1" > file
fossil commit file -m "Initial content" # succeeds
echo "Branch 2" > file
fossil commit file -m "Subsequent content" # fails
This is on a repo where mtime-changes is unset. If I set it to 'off',
the test passes.
I think the fault is this chunk from vfile.c:
if( (chnged==0 || chnged==2 || chnged==4)
&& (useMtime==0 || currentMtime!=oldMtime) ){
/* check SHA1 hash here */
}
If the file size hasn't changed, then chnged is 0 as Fossil doesn't know
it's changed yet. If useMtime is 0 and the modification time falls
within the same second window as the original, then the condition never
fires and the SHA1 hash is never calculated.
I think that should be:
if( (chnged==0 || chnged==2 || chnged==4)
|| (useMtime && currentMtime!=oldMtime) ){
...that is, check the SHA1 hash if the file is thought to be unchanged
*or* if useMtime is set *and* the mtime has in fact changed.
However I'm sufficiently unconfident about my analysis to actually go
and try it. Thoughts?
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ "There does not now, nor will there ever, exist a programming
│ language in which it is the least bit hard to write bad programs." ---
│ Flon's Axiom
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
