re: [rdiff-backup-users] Re: 1) Using samba to backup windows shares 2) sparse files

[Greg Freemyer]

Be warned that FAT and NTFS have a bug.

Everytime Daylight Savings Time kicks in or out, all files get their GMT 
timestamp changed by 1 hour.

Thus rdiff-backup may do a full backup on those dates.  

I have not tested this, so I don't know the details.

Greg

 >>  I think i figured out the first part of my problem
 >>  when backing up windows files (with samba): It seems
 >>  that FAT and NTFS are not as accurate in reporting
 >>  the modification date of a file so that file is
 >>  flagged as changed even though it is not changed. 
 >>  A solution to this problem would be a flag to
 >>  rdiff-backup similar to rsync  --modify-window to
 >>  allow a 2-second difference as being the same date.
 >>  By the way, i suggested in my first email that the
 >>  modification time was changing by 1/100 of a second;
 >>  that was a mistake: the change is 1 second.

 >>  Any comments on my second question regarding
 >>  rdiff-backup and possibility of improving it to
 >>  allow for sparse file checking and subsequent sparse
 >>  file writing? This would be quite useful for saving
 >>  a lot of space (20% in our lab) and more importantly
 >>  for not running out of space due to the backup
 >>  taking more space than the original (which has some
 >>  sparse files).

 >>  Thanks a lot!

 >>  Stelios 

 >>  ps: Here is a relevant message on the windows
 >>  timestamp issue
 >>  Windows timestamps (was RE: Speed of rsync under Win95)
 >>  David Bolen address@hidden
 >>  Thu, 6 Jul 2000 20:01:23 -0400

 >>  Michael Salmon address@hidden writes:

 >>  > The timestamp on fat/vfat systems is the actual
 >>  time and date which
 >>  > means that there was only 5 bits left for the
 >>  seconds so it has a
 >>  > granularity of 2 seconds. Interestingly the only
 >>  place I could find
 >>  > this documented was in the samba source code.

 >>  For what it's worth, I just ran into this under NT
 >>  as well, and
 >>  thought the following excerpt from docs for the
 >>  Win32 GetFileTime call
 >>  might be useful:

 >>  Note: Not all file systems can record creation and
 >>  last access time
 >>  and not all file systems record them in the same
 >>  manner. For
 >>  example, on Windows NT FAT, create time has a
 >>  resolution of 10
 >>  milliseconds, write time has a resolution of 2
 >>  seconds, and access
 >>  time has a resolution of 1 day (really, the access
 >>  date). On NTFS,
 >>  access time has a resolution of 1 hour. Therefore,
 >>  GetFileTime may
 >>  not return the same file time information set
 >>  using the SetFileTime
 >>  function. Furthermore, FAT records times on disk
 >>  in local
 >>  time. However, NTFS records times on disk in UTC,
 >>  so it is not
 >>  affected by changes in time zone or daylight
 >>  saving time.

 >>  The GetFileTime function is documented for all of
 >>  Win95/98/NT, but the
 >>  commentary above doesn't explicitly cover 95/98,
 >>  although for FAT it would
 >>  make sense to be similar.

 >>  rsync uses "write time" (modification) for its
 >>  decision making
 >>  process, so even under NT and even with NTFS (which
 >>  surprised me)
 >>  you've got a 2s granularity.

 >>  The bit about NTFS storing in UTC seems to me to
 >>  also have the
 >>  potential to cause problems at some point but I
 >>  haven't been able to
 >>  test yet (we push to FAT systems in the field).  I'm
 >>  not quite certain
 >>  what would happen if rsync retrieved a time from an
 >>  EST NTFS file
 >>  (which it sounds like converts from UTC to local
 >>  time), then transmits
 >>  that time_t over to the remote system (say a PST
 >>  NTFS file).  It would
 >>  be ok unless one of the timezones had to change, in
 >>  which case the
 >>  files would seem out of whack, if I'm thinking about
 >>  it correctly.

 >>  -- David
 >>  \               David Bolen            \   E-mail:
 >>  address@hidden  /
 >>  |             FitLinxx, Inc.            \  Phone:
 >>  (203) 708-5192    |
 >>  /  860 Canal Street, Stamford, CT  06902   \  Fax:
 >>  (203) 316-5150     \


 >>  ----- Original Message -----
 >>  From: "Stelios K. Kyriacou" <address@hidden>
 >>  Date: Tuesday, June 17, 2003 3:10 pm
 >>  Subject: 1) Using samba to backup windows shares 2)
 >>  sparse files (fwd)

 >>  > 
 >>  > 
 >>  > ---------- Forwarded message ----------
 >>  > Date: Thu, 8 May 2003 22:28:52 -0400
 >>  > From: Stelios K. Kyriacou <address@hidden>
 >>  > To: address@hidden
 >>  > Subject: 1) Using samba to backup windows shares
 >>  2) sparse files
 >>  > 
 >>  > 
 >>  > Hi
 >>  > 
 >>  > First, I would like to thank Ben Escoto for a very
 >>  useful
 >>  > program. I use it routinely for backups of our
 >>  home directories in 
 >>  > linuxand also for backing up some data from
 >>  windows 2000 using 
 >>  > samba mounting.
 >>  > I find the program quite easy to use and easy to
 >>  restore single 
 >>  > files! I
 >>  > have two issues to discuss:
 >>  > 
 >>  > By the way i use rdiff-backup 0.11.0 and redhat 8.0
 >>  > 
 >>  > First issue: I noticed that somehow the
 >>  modification time stamp 
 >>  > from a
 >>  > windows 2000
 >>  > may change by 1/100th of a second (i think it is a
 >>  fluke and not a 
 >>  > realchange) and thus files are being shown as
 >>  > modified and thus backed up ... anybody has
 >>  > seen this too? here is an example:
 >>  > I first restore all the modified backups of a
 >>  single file to see 
 >>  > what is
 >>  > happening:
 >>  > for i in HipStructureAnalysis.vbw* ; do
 >>  rdiff-backup $i trash_$i ; 
 >>  > done
 >>  > The command stat shows:
 >>  >  File:
 >>  "trash_HipStructureAnalysis.vbw.2003-04-12T01:02:02-
 >>  > 04:00.diff.gz"  Size: 847             Blocks: 8  
 >>  IO Block: 
 >>  > 4096   Regular File
 >>  > ...
 >>  > Modify: Fri Apr 11 17:01:59 2003
 >>  > 
 >>  >  File:
 >>  "trash_HipStructureAnalysis.vbw.2003-04-14T01:02:01-
 >>  > 04:00.diff.gz"  Size: 847             Blocks: 8  
 >>  IO Block: 
 >>  > 4096   Regular File
 >>  > ...
 >>  > Modify: Fri Apr 11 17:01:58 2003
 >>  > 
 >>  > So I see a 0.01 second difference in file
 >>  modification date which i 
 >>  > thinkis a fluke of windows?
 >>  > 
 >>  > The second issue: Is there any interest in getting
 >>  a --sparse option
 >>  > similar to rsync so as to save some space? I am
 >>  dealing with simulated
 >>  > images backups and it could be 20% savings in
 >>  space which is a lot. I
 >>  > would love to have this feature! Now i may have to
 >>  revert to rsync 
 >>  > justfor this reason.
 >>  > 
 >>  > Thanks a lot in advance!
 >>  > Stelios
 >>  > 
 >>  > 
 >>  > 
 >>  > 



 >>  _______________________________________________
 >>  rdiff-backup-users mailing list
 >>  address@hidden
 >>  http://mail.nongnu.org/mailman/listinfo/rdiff-backup-users