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

[STELIOS KYRIACOU]

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
> 
> 
> 
>