On Sat 03 Feb 2007, Marc Lehmann wrote: > > Today I found that rsync transfered the same (unchanged) file everytime I ran: > > rsync -avHxP / remotehost:dir/. --del > > Turned out that the source file had a very old timestamp: > > -rw-r--r-- 1 root root 573153 Jan 1 1970 file > > File: `/root/movies/SF-ebooks/Dragonlance/Dragonlance Preludes 1 vol 2 - > Kendermore.txt' > Size: 573153 Blocks: 1120 IO Block: 4096 regular file > Device: 802h/2050d Inode: 184913758 Links: 1 > Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2005-07-30 17:07:50.350691000 +0000 > Modify: 1969-12-31 23:59:59.000000000 +0000 > Change: 2005-12-05 14:59:12.234944320 +0000 > > Fascinatingly enough, stat -c%Y says -1 seconds since the epoch.
I think that epoch - 1 is not really defined, so behaviour of apps when presented with this is undefined... > > The destination file has a very different timestamp: > > -rw-r--r-- 1 root root 573153 Feb 7 2106 file > > File: `Dragonlance/Dragonlance Preludes 1 vol 2 - Kendermore.txt' > Size: 573153 Blocks: 1121 IO Block: 131072 regular file > Device: fd00h/64768d Inode: 3276970 Links: 1 > Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2007-02-03 18:34:49.000000000 +0000 > Modify: 2106-02-07 06:28:15.000000000 +0000 > Change: 2007-02-03 18:34:49.000000000 +0000 > > which likely is the reason it transfers the file again and again. > > stat -c%Y says 4294967295 (0xffffffff, or less precisely, -1 & (2**32-1)). > > the source system is 32 bit, while the remote system is 64 bit, btw. time_t is actually an unsigned value I believe, so interpreting the 0xffffffff as a positive value would be the correct behaviour. That said, I agree that rsync shouldn't repeatedly transfer this file. I'll investigate what the best course of action would be. Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
