On Wed, May 02, 2001 at 11:31:31AM +0100, John N S Gill wrote:
> For some time I've been using rsync to sync up some NT file folders and
> it has been working like a treat.
> 
> I use smbmount to mount the NT shares to linux boxes at each end of the
> link and then let rsync do the rest.
> 
> Last week the linux boxes were upgraded to redhat 7.1.  I am now using
> the following packages:
> 
> samba-2.0.7-36
> samba-client-2.0.7-36
> rsync-2.4.6-2
> 
> Since the upgrade i am finding the modify times on the receiving end of
> the job are 2 seconds off from the sending end.
> 
> When I use 'ls -l --full-time' on the NT shares i see that all the
> timestamps on the receiving end have an even number in the seconds
> column.  On the sending end I see a mixture of odd and event seconds
> (note most of the files on the sending end were created by users running
> NT itself).
> 
> It looks like smbmount/samba can only set the time on my NT shares to
> the nearest 2 seconds, but the problems I'm seeing aren't quite that
> simple.
> 
> For instance I see thinks like this:
> 
> (sending machine)
> drwxrwx---    1 rems     rems      512 Wed Mar 21 09:08:40 2001 X/XYZ
> 
> (receiving machine)
> drwxrwx---    1 rems     rems      512 Wed Mar 21 13:08:38 2001 X/XYZ
> 
> If it was as simple as having to round to nearest even time then there
> should be no problem if the time stamp at the sending end had an even
> time.
> 
> I'm not sure if this is a bug or a feature + if it is a bug whether it
> is rsync, samba or NT that is causing the problem.
> 
> The good news is that there is an easy work-around, I have added:
> 
>      --modify-window 2
> 
> to my rsync options.
> 
> However, I'd prefer not to have to do this. 


If I remember correctly, that's precisely why that option was added.  I'm
not sure why you didn't see the problem before.  Ah yes, see
    http://lists.samba.org/pipermail/rsync/2000-July/002503.html
which says it defaults to "2" on Windows.  It would be good if the man page
said it should be 2 when dealing with a FAT filesystem.

- Dave Dykstra

Reply via email to