re[2]: [rdiff-backup-users] Weird FAT/NTFS timestamps

[Greg Freemyer]

 >>  >>>>> "GF" == Greg Freemyer <address@hidden>
 >>  >>>>> wrote the following on Tue, 1 Apr 2003 09:58:25 -0500

 >>  GF> All, I just read an e-mail where Windows keeps all filesystem
 >>  GF> file timestamps in local time.

 >>  GF> This means that when DST (Daylight Savings Time) kicks in/out,
 >>  GF> the date/time for all files on your disk are changed by 1 hour.

 >>  GF> Apparently this causes rsync problems if you are not using the
 >>  GF> --checksum option.

 >>  GF> Are there any rdiff-backup gotcha's along the same lines?

 >>  I just saw that there were a lot of messages on the rsync list about
 >>  this, but I don't know what the upshot is.  rdiff-backup just compares
 >>  the times returned by lstat, which are supposed to be in seconds since
 >>  the epoch I think.

 >>  I'm not sure how this would result in a problem.  Maybe if the switch
 >>  to daylight savings, an rdiff-backup session, and a file update
 >>  happened within the same hour, and the file was updated exactly an
 >>  hour after the first update, then the new version wouldn't be backed
 >>  up?


 >>  -- 
 >>  Ben Escoto

Ben,

My reading of the e-mail was the Windows FAT and NTFS filesystems have a bug.

The bug causes the cygwin lstat time returned during normal time and during DST 
are different.  (They vary by 3600 secs.)

I suspect it also affects either type of volume directly mounted on a Linux box.

Rsync sees this change in lstat values as a file update and transfers 100% of 
the files on the first run after a DST change.

Would rdiff-backup also do this, or does it exclusively use block level 
checksums?

Greg