Howdy...
Fortunately you posted the KB article number, and having read the article, I
see you have a bit of a misunderstanding of what is going on.
First off, NT/2000 uses a offset from GMT, which does not observe Daylight
Savings Time (DST), for storing the time in the Event Log, and NTFS
No matter what my understanding's like: the timestamps on the files changed
after last weekend, resulting in a mismatch between source and destination
files. I've changed the clock to a timezone one hour ahead to compensate,
did a F5 in a particular folder and miraculously the timestamps followed
On Tue, Oct 29, 2002 at 09:06:26PM +0100, [EMAIL PROTECTED] wrote:
No matter what my understanding's like: the timestamps on the files changed
after last weekend, resulting in a mismatch between source and destination
files. I've changed the clock to a timezone one hour ahead to compensate,
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
Howdy...
The short answer is the DST issue affects volumes using the NTFS filesystem.
The long answer is contained in the Windows KB article that was posted.
I am looking at a solution for this problem, along with a few other issues,
but the solution is a few months off from now.
Wolfe
--
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
Howdy...
I have a printout of the manpage, and the -t states to transfer the
modificaiton time along with the file. This is to place the same modication
time on the file when it is transferred, rather than the current time.
The easiest way to get around this issue is to use the -c or
