Philipp Marek wrote, On 07/03/07 14:22:
I would expect test.txt to be reported as Changed... am I missing
something?
No. AFAIK (without looking) sync-repos has a small bug, in that files *with
the same size* are not reported as changed, because their mtime is read after
syncing. (See mtime, ctime stamps above).
Bug:
$ fsvs st -C -C
should report it (doing a checksum), and
$ fsvs commit -C -C
too.
yep... -C -C was my *workaround*...
but... on *big* directory (5095 files/dirs) I get Bus error when using
-C -C (without... it works as expected...):
fsvs ci -m "<snip>" -C -C -d
<snip>
23:10:50.733 hlp__lstat[helper.c:316]
./var/html/galleries/pages/144.php: uid=700 gid=700 mode=0100664
dev=0xfd07 ino=774597 rdev=0x0 size=23949
23:10:50.733 ops___stat_to_action[est_ops.c:274] change = 24
23:10:50.733 cs__compare_file[checksum.c:280] checking for modification
on ./var/html/galleries/pages/144.php
23:10:50.733 cs__compare_file[checksum.c:282] hashing
./var/html/galleries/pages/144.php
23:10:50.733 cs___end_of_block[checksum.c:498] manber reinit
23:10:50.733 cs___end_of_block[checksum.c:595] on return at fpos=0:
00000000 (databits= 0)
23:10:50.733 cs__compare_file[checksum.c:322] mapping 24703 bytes from 0
23:10:50.734 cs___end_of_block[checksum.c:579] manber found a border:
19714 F2AED6B5 45D40000 f065e5c2f2568c70de54a8f9f806a199
23:10:50.734 cs___end_of_block[checksum.c:595] on return at fpos=19714:
45D40000 (databits=7f)
Program received signal SIGBUS, Bus error.
[Switching to Thread -1208153728 (LWP 10517)]
0x0804b040 in cs___end_of_block ()
(gdb) bt
#0 0x0804b040 in cs___end_of_block ()
#1 0x0804bed7 in cs__compare_file ()
#2 0x0804fec1 in ops__update_single_entry ()
#3 0x0805b30d in waa__update_tree ()
#4 0x0805bc67 in waa__partial_update ()
#5 0x0805bd21 in waa__read_or_build_tree ()
#6 0x0804d136 in ci__work ()
#7 0x08050c72 in main ()
So, BTW ... why does your fsvs give no MD5 of that file?
$ fsvs info big_file
.... 588888 ./big_file
Type: file
URL: file:///tmp/ram/fsvs-test-1000/repos/trunk/big_file
Status: 0x0 (unmodified)
Flags: 0x0 (none)
Dev: 20
Inode: 16306
Mode: 0100644
UID/GID: 1000 (flip)/1000 (flip)
MTime: Wed Mar 7 19:57:53 2007
CTime: Wed Mar 7 19:57:53 2007
WAA-Path: /tmp/ram/waa/be/9b/c359b8d47483ea64ef5faa12ac2d/
Revision: 4
Repos-MD5: 9f588ff5001de34673652c4a767575e4
Size: 588888
$ echo 'Hello world!' | md5sum
59ca0efa9f5633cb0371bbc0355478d8 -
Could you please check whether fsvs really prints no MD5 for you?
Why not?
Hmmm... probably because info was applied on the directory "." ("fsvs
info" without any path)... not on test.txt...
$ fsvs info
.... 4096 .
Type: directory
<snip>
Here on text.txt
$ fsvs info test.txt
.... 15 ./test.txt
Type: file
URL: file:///tmp/fsvs-test-repos/test.txt
Status: 0x0 (unmodified)
Flags: 0x0 (none)
Dev: 64772
Inode: 16421
Mode: 0100664
UID/GID: 700 (webmaster)/700 (webmaster)
MTime: Wed Mar 7 09:40:42 2007
CTime: Wed Mar 7 09:40:42 2007
WAA-Path: /tmp/fsvs-test-waa/c8/7a/49247ae33399f07ced864e301e46/
Revision: 3
Repos-MD5: fd26eea2963d107fc314d4b92cc14333
Size: 15
And now to your point - should fsvs on a sync-repos *always* check the local
files for identity? (Doing a MD5?) Would be slow.
I would expect any synchronization function (probably only used when
things go wrong...) to set the wc ready to be use as *business as
usual*... and not having to care about using additional arguments on
subsequent commands to be sure it's the case. A quick fix (?) could be
to have something like:
fsvs sync-repos [-r rev] [-C [-C]]
So the user can decide between speed and the checksum peace of mind...
Should it do that always on status? Probably not.
I agree. Status needs no change.
But you're right, in that it could see the differing mtime, and say "possibly
changed" - as it does with other files.
How's r726 for you?
Better. But [-C [-C]] on sync-repos would be perfect! ;-)
Ben.
