If I understand the manpages correctly, if you use -t, the criterium for
syncing files is the difference in timestamp, not in size.
There are plenty of situations where the size of a file stays identical,
while it's contents has changed.
If you omit -t, all files are synced.
Rgds,
Bart Coninckx
Network Administrator
CNE, ASE
*************************************
Watco ICT Services
Lilsedijk 19
B-2340 Beerse
Belgium
e-mail: [EMAIL PROTECTED]
Tel: + 32 (0) 14 60 99 42
Fax: + 32 (0) 14 62 41 47
*************************************
========================== Disclaimer ==================================
The information in this email is confidential, and is intended solely for
the addressee(s). If you are not the intended recipient of this email
please let us know by reply and then delete it from your system;
you should not copy this message or disclose its contents to anyone,
not even by forwarding it.
Due to the integrity risk of sending emails over the Internet,
Sita ICT will accept no liability for any comments and/or attachments
contained within this email.
========================== Disclaimer ==================================
Lachlan Cranswick
<l.m.d.cranswick@ To: [EMAIL PROTECTED]
dl.ac.uk> cc:
Sent by: Subject: Re: important caveat with
Rsync on NT and dayligt savings time
rsync-admin@lists
.samba.org
10/29/2002 21:35
I think this "day light savings" time stamp issue also affects
Win98 as well - at least on a Win98 PC I use.
Rsync insists on updating all the files fully.
Shouldn't it just be resetting the times on the files
if the files are the same size - or am I missing
something here?
Lachlan.
>Your description is as confusing as the KB article (at least
>to me). Part of the problem with the KB article is that it
>focuses on localtime displays rather than internals.
>
>.From what i can tell FAT stores timestamps in localtime.
>NTFS uses a GMT based timestamp.
>
>I can see one of two places where we get bit. As a matter
>of curiosity i'd like to know which.
>
>1. When the FAT timestamps are converted to GMT it is done
> based on the current TZ offset rather than the TZ offset
> in effect when the timestamp was made.
>
>2. The NT equivalent of stat(2) is converting the NTFS
> timestamps to localtime and then the cygwin libs convert
> it back to GMT.
>
>It would appear that the problem could be avoided either by
>using NTFS or FAT filesystems. Yes? It certainly sounds
>filesystem dependant.
>
>I'd guess that the correct place to fix this is in the
>cygwin libs. They could be tweaked to recognize the TZ
>calculation error of the NT libs. There might need to be a
>test for filesystem type (if possible) or a switch to
>determine behavior otherwise what fixes some will break
>others.
-----------------------
Lachlan M. D. Cranswick
Collaborative Computational Project No 14 (CCP14)
for Single Crystal and Powder Diffraction
Birkbeck University of London and Daresbury Synchrotron Laboratory
Postal Address: CCP14 - School of Crystallography,
Birkbeck College,
Malet Street, Bloomsbury,
WC1E 7HX, London, UK
Tel: (+44) 020 7631 6850 Fax: (+44) 020 7631 6803
E-mail: [EMAIL PROTECTED] Room: B091
WWW: http://www.ccp14.ac.uk/
--
To unsubscribe or change options:
http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
