View Ticket
Not logged in
Ticket UUID: b14f8788191f6e05253c4c9353231b6a63f18994
Title: Line ending changes cause fossil to not detect differences for commit
Status: Open Type: Code_Defect
Severity: Priority:
Subsystem: Resolution: Open
Last Modified: 2010-12-17 21:10:26
Version Found In: This is fossil version [e3313965d3] 2010-12-15 02:42:29 UTC
Description & Comments:
In a large project, I get errors like this on a commit:
ERROR: [root/user/test/zero/Makefile] is 61 bytes on disk but 64 in the repository

The only difference between the previous version and this is that the line endings changed from dos style to unix style.

I tried to reproduce it with a small file, but I get bizarre behaviour with fossil sometimes detecting the change, but sometimes not.

Looks like things work in this small example if I put a "sleep 1" before the commit, but they don't otherwise. On the bigger example, I just can't get the file to commit. It either gives the ERROR when I don't specify any filename, or says "nothing has changed" if I give it the explicit filename

$ fossil open f
$ echo a > a
$ fossil add a
ADDED  a
$ fossil commit -m 1 a
New_Version: 54592e024b956e96eecba85541914675c6454aa7
$ unix2dos a;  fossil commit -m 1 a; dos2unix a;  fossil commit -m 1 a
unix2dos: converting file a to DOS format ...
New_Version: aa6d03e4ea89aa9885463c44f6747d583b60eb59
dos2unix: converting file a to UNIX format ...
fossil: ancestor check-in [aa6d03e4ea] (2010-12-15 07:11:53) is not older (clock skew?) Use -f to override.
$ unix2dos a;  fossil commit -m 1 a; dos2unix a;  fossil commit -m 1 a
unix2dos: converting file a to DOS format ...
New_Version: 351b9813df675e832d63b7bcfe098b5c4373e80e
dos2unix: converting file a to UNIX format ...
fossil: nothing has changed
$ unix2dos a;  fossil commit -m 1 a; dos2unix a;  fossil commit -m 1 a
unix2dos: converting file a to DOS format ...
fossil: nothing has changed
dos2unix: converting file a to UNIX format ...
fossil: nothing has changed
$

anonymous added on 2010-12-15 08:06:12:
I think that Windows filesystems (at least fat32) has timestamps only every two seconds. And at best, every second like unix.

Some files may be changed and remain with the same timestamp, and it may be a cause why fossil does not find anything new, but it finds so after a 'sleep'.


venks added on 2010-12-15 15:48:33:
On the big project waiting any amount of time doesn't help, I still get the errors - it's like fossil remembered the state with the wrong line endings.

Time has something to do with it - I'm fossilizing an old project from out of tar.gz files, so there are lots of quick commits with a large number of files, and the files have old timestamps. I'm guessing the previous commit already messed it up somehow.

The files have windows line endings, but I'm on linux, although an old one:

Linux yukon.comit.com 2.6.11-1.1369_FC4smp #1 SMP Thu Jun 2 23:16:33 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux

venks added on 2010-12-15 18:16:11:
Thanks to drh. This is fixed by using fossil status -sha1sum to detect changes. Feel free to close this.


anonymous claiming to be viric added on 2010-12-17 21:10:26:
Related, there is the "repo-cksum" setting.