[<<]Message[>>]    [<<]Author[>>]    [<<]Subject        [<<]Thread    

Number   :  9109
Date     :  2004-11-02
Author   :  John Zeman
Subject  :  Re: Unexpected results all of a sudden
Size(KB) :  3



> The source of your problem is that one set of files are on
> a FAT volume and the other set are on an NTFS volume. The
> timestamp of a file on a FAT volume is recorded using local
> time. The timestamp of a file on an NTFS volume is recorded
> using UTC time.
> 
> When you change the regional setting to a different time zone
> or daylight savings starts or ends, the timestamp of files on
> either volume DOES NOT change. However the timestamp of files
> on an NTFS volume APPEARS to change. When windows retrieves
> the timestamp for NTFS files and passes that time to the
> calling program, it adjusts the UTC time to reflect the local
> time zone and/or daylight savings. Therefore although the UTC
> time is unchanged, Explorer or Cmd or Xxcopy or whatever
> generally uses/displays the time using local time and this
> appears to show an altered timestamp.
> 
> This wouldn't cause a problem if comparing files between two
> different NTFS volumes because the time adjustment would be
> the same for both the src and dst. The problem arises when
> comparing files on a FAT volume because these times are
> stored using local time. Windows makes no time zone
> adjustment for these files so their timestamps both remain
> the same AND appear the same irrespective of timezone/
> daylight savings changes. However when the file timestamps
> are compared to the files on a FAT volume, they appear to
> have different timestamps.
> 
> There isn't really any good solution to this. If you disable
> daylight savings adjustment and/or change the system clock
> whenever daylight savings starts/ends, the PC is going to
> appear to the user to have an incorrect time. Also on
> OS's like XP that use time servers by default, it can
> actually be quite a challenge to deliberately maintain
> the system with the "incorrect" time.
> 
> The easiest solution is to do as John suggests and use a
> larger fuzzy time (bearing in mind that files altered within
> the last hour won't get copied). If you have a predictable
> environment such as backing up to an external drive, you
> could possibly use a batch file and the various /TT, /TD-
> or /TS+ or even /FU to make the necessary adjustments but
> I'm not sure that it's worth the effort.
> 
> Garry



Thanks for the very informational reply Garry, that makes sense to me.

I need to correct something I said in error though. I had mentioned 
that using the fuzzy file time option of /FF3602S would treat files 
within 1 hour and 2 seconds of each other as being identical, and it 
does. IF the time stamps of the source and destination files are 
within 1 hour and 2 seconds of one another.

That's where I made my error. I was wrongly thinking the 1 hour and 
2 second differential is in comparison to the current time. It's not 
the current time, it's the time stamps of the source and destination 
files.

So unless someone is backing up their system every few minutes, using 
a fuzzy file time like /FF3602S shouldn't cause any problems at all. 
And even if they are backing up their system every few minutes it 
only means the backup is 1 hour and 2 seconds behind the current file 
system.

John



This message if part of XXCOPY's message Archive.
The archive contains all the messages posted at Yahoo!Groups: XXCOPY.