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

Number   :  3182
Date     :  2002-12-02
Author   :  Kan Yabumoto
Subject  :  Re: Suddenly frustrated, then baffled, then...
Size(KB) :  12


Chaz:

I'm not sure if I agree with your characterization of what is happening.

>What I didn't understand is why Microsoft would have tied the system clock
>to the file system in the first place. If I'm on a machine set to EST and
>I save a file at 12:00p, then copy it over to another machine set to PST I
>would expect the time stamp to stay 12:00p. It seems they went out of
>their way to corrupt this situation by "seeing" timestamps as other than
>absolute; that is, making the time stamp consider the system time of the
>machine where the file resides.

In all Win32 environments, the file systems, both FAT and NTFS always
have used the UTC value to store the timestamp in the directory.
I believe this is a proper behavior. It makes Windows somewhat closer
to the more-ideal, but more simplistic Unix method. But, Microsoft
had to deal with backward-compatibility issues. I believe they did
their best under the circumstance.

Having files stamped with a universal timestamp makes it automatically
easy to compare and move files from one time zone to another. Actually,
we are blessed with the UTC-based timestamps so that time-zone
related problems are restricted to certain class of files only
(see below).

When you compare a file created on Machine A and 10 minutes later,
you created another file on Machine B, when you compare the two
files for which one is more recently made, the Windows system
provides correct answer (provided that the both machines have reasonably
accurate time settings ---- regardless of their time-zone settings).

Just for the sake of user-convenience, Windows (and most applications
programs including XXCOPY) perform UTC-to-local time conversion before
display (and, we expect user-specified-timevalues in a local value).
But, internally, we (Microsoft and we at Pixelab) talk one another
pretty much in UTC format behind the scene.

The only problem is when a file is transported via a physical media
such as floppy or CD-ROM, then, the time found on the media will be
always treated as if the timestamp was created on a local reference.
(I'm not sure my phrasing here is correct to explain this situation).
Let me give you an example; on my Windows XP-Pro machine,
if I examine the timestamp of C:\WINDOWS\SYSTEM32\ANSI.SYS it shows
the file date of 2001-08-23 05:00:00 which I believe is the official
WinXP release date (pre-SP1 version). Even though I am at the Chicago
time zone, this file shows the file was made 5:00 am that day.
Now, if you examine the same file on your system at a different time
zone, you will still find the file (which was mass-distributed by
Microsoft from the same file), it will show you that the timestamp
of the same file was made also at 5:00 am in your time zone. That
is, the identically made files (travelled with the CD-ROM), exhibit
different time (in UTC-converted format). Therefore, if your computer
and my computer are connected via a network and perform a timestamp
comparison, we will find the two files have difference which equals
to the time-zone difference between us. That is when you need to use
the /TD and /TS feature to compensate the difference. Since all
user-created files are compared with UTC-adjusted value, if you
choose /BN (backup newer one), you will get more recent one.

So, the funny problem is confined to files that travels with
a physical storage device (floppy, CD). Also, a zipped file you
download behaves very much like a floppy disk. The XXCOPY release
version's timestamps will show exactly the same "local" time value
regardless of wherever you are in the world. For other network-based
file transfer, there are no such problems.


Let me comment on your current problem:
-------------------------------------------------------------------------
If you have two machines side by side, and one is set to EST and
another one at PST, then, you must set the clocks of the two macines
with 3 hour difference. That is, the two machine must match in their
UTC-converted time. If you keep the EST and PST settings respectively,
and you force the local time (the one you see every day) of the two
machine identically, that is your problem. You should not do that.
Or, at least one machine is set three hours wrong!!!

Now, computers are expected to move from one time zone to another.
So, you change your laptop's time-zone from PST to EST. But, that
would not change anything to the files on your system. They have
been recorded in UTC format. That is, changing your time-zone
setting or even the current system time will not change any of
the files's timestamp value (their time display in local value
will reflect the change superficially). That is, if you created
a file 10 hours ago, the file will exhibit as 10-hour-old file
regardless of how you manipulate the time zone of the machine.
The age of the file remains consistent with your age (we all
age at exactly the same rate). So, if you have timestamp
problems, you need to work harder than just changing the time zone
settings.
-------------------------------------------------------------------------

In conclusion, the timestamps are always somewhat confusing.
But, usually it helps to think in UTC (and how old the files are).

Kan Yabumoto
===================================================================


At 2002-12-02 14:17, you wrote:
>Thanks, Kan. Yes, I knew about both of the switches; in my example you can
>see I routinely use /FF3 because of the NTFS and FAT issue.
>
>What I didn't understand is why Microsoft would have tied the system clock
>to the file system in the first place. If I'm on a machine set to EST and
>I save a file at 12:00p, then copy it over to another machine set to PST I
>would expect the time stamp to stay 12:00p. It seems they went out of
>their way to corrupt this situation by "seeing" timestamps as other than
>absolute; that is, making the time stamp consider the system time of the
>machine where the file resides.
>
>I could understand that if I went to the PST machine five minutes later and
>opened and then saved the file, the time stamp would change 09:05a. I just
>don't know why they did it the way they did.
>
>For my purposes, it was only a mistake on my part that caused my
>frustration. I should have reset the clock on the laptop back to EST
>before trying another backup. This explains why, with the erroneous setup
>I used, XXCOPY decided to copy all the files. What it doesn't explain is
>why it would copy them all again when I ran the .bat job immediately
>thereafter.
>
>Curious.
>
>BTW, thanks to you and your team for a tremendous productivity tool that
>XXCOPY is!
>
>Chaz
>
>At 02:57 PM 12/2/2002, you wrote:
> >Chaz:
> >
> >There could be two problems that may be making the situation difficult.
> >
> > 1. The time-zone difference in the two machines.
> > 2. the granularity of the file systems (FAT vs NTFS)
> >
> >---------
> >
> >1. When you have two machines whose local time is set differently,
> > you have to compare one mahcine's file to another machine's file
> > (when connected via a network), by the UTC version of the time.
> > That is, when the timestamps are compared between two volumes,
> > the timestamps are always converted to its respective UTC timestamps.
> >
> > To test this scenario, you should use the following command to
> > see the timestamps in UTC
> >
> > xxcopy c:\mydir\*.doc /LDTL /FU // list timestamp in UTC
> >
> > Here, the timestamps is displayed in the UTC (like GMT) value.
> > Do the same on your two machines to see if times are different.
> > If the two machine's time zone settings are different, even if
> > the respective filetimes in local time are the same, the
> > timestamp comparison always uses the UTC version.
> >
> > There are special switches (/TS+ /TS-, /TD+ and /TD-)
> > that are specifically designed to add or subtract certain offset
> > value in the timestamp comparison. As a matter of fact, these
> > switches were invented specifically to deal with time-based
> > backup across time zones. If you the source machine is one hour
> > ahead of the destination machine in its time-zone setting, you may
> > use /TS-1 or /TD+1 (either subtract 1 hr from source or add 1 hr
> > to the destination) to compensate the time zone difference.
> > The difference between /TS and /TD is that the /TS will adjust
> > the value of the timestamp of the source before the comparison
> > and the subsequent copy operation whereas the /DS version will
> > adjust the timestamp of the destination before the comparison
> > operation. The net difference of the two is that when you overwrite
> > a file, the /TS version will save the adjusted time in the newly
> > created file whereas the /TD version will discard the adjusted
> > time (because it will be overwritten by the unadjusted value).
> >
> >2. When you mix an NTFS volume and a FAT volume in timestamp
> > related operations, you need to be aware that the granularity
> > of the two are different. Add /FF to allow plus/minus 2 seconds
> > in time mismatch which will still be treated as a match.
> > It is relatively easy to tell whether the granularity mismatch
> > is the source of the problem. Just list a few files using the
> > XXCOPY /LDTL operation and see if the files in the NTFS file
> > has an odd-numbered seconds in the timestamp. Since the FAT
> > file system has a granularity of 2 seconds, all files will be
> > can store with an even-numbered timestamp. Although you may
> > adjust the range of the slack in timestamp comparison by an /FF
> > parameter, usually the default 2 second range is the best and
> > you should not increase the slack value to more than what is
> > needed.
> >
> >You may combine both the /TS/TD and /FF at the same time. But,
> >if /TS/TD solves the problem, don't use /FF. It's not clear
> >whether you need both. But, under the circumstance, you may need
> >both.
> >
> >
> >Kan Yabumoto
> >==================================================================
> >
> >At 2002-12-02 00:44, you wrote:
> > >For the past two years (approx) I've been using a large XXCOPY batch 
> job to
> > >synchronize certain files between my tower computer and my laptop.
> > >
> > >The tower currently runs XP Home and uses NTFS. The laptop runs Win98SE
> > >and uses FAT32.
> > >
> > >As I say, things have been working just fine for some time, copying only
> > >new/updated files from the tower to the laptop, cleaning up files in the
> > >destination that no longer exist in the source.
> > >
> > >But, in the last 24 hours, when I run the batch job (I'll give an example
> > >of one of the lines shortly), XXCOPY does the work but I observed it
> > >copying old files that already existed on the laptop. If I then
> > >immediately run it again, it copies the same files again. If I look 
> at the
> > >files on both machines they are identical in name, size, creation date.
> > >
> > >Here's one of the lines that behaves this way (I have h: mapped to the 
> root
> > >of the laptop drive):
> > >
> > >xxcopy "f:\documents and settings\chaz cone\my documents\" "h:\documents
> > >and settings\chaz cone\my documents\" /clone/ff3/yy
> > >
> > >The folders exist on both machines. XXCOPY puts up no errors, just does
> > >the work again. (and again, and again if I try again).
> > >
> > >I'm using 2.82.6 Pro (and I realize it's a backlevel version) but it's 
> been
> > >working until today just fine and I always hesitate to change something
> > >that's working. I was baffled.
> > >
> > >Then I remembered that I'd changed the system time on the laptop when I
> > >took it on the road last week. I'm in Eastern time and I changed the
> > >laptop to Pacific time. I neglected to put it back when I came home. So,
> > >apparently the only new difference between the two machines' setup is the
> > >time the system clock shows on the laptop. And this apparently has
> > >corrupted the time stamp evaluation that XXCOPY makes (at least in this
> > >version). It sees the files as needing to be copied even though the
> > >timestamps are identical - perhaps because of the difference in system 
> time.
> > >
> > >I reset the system time in the laptop and tried again. It didn't
> > >help. THEN I rebooted the laptop and tried again and now it works just
> > >fine as it always did. It looks like Win98SE observes the system time and
> > >somehow adjusts the file date/time internally? Or something?
> > >
> > >At any rate, I'm working again..
> > >
> > >Unless this is a version dependent situation that affects only backlevel
> > >folks (like me) maybe this could explain woes others have reported when
> > >backing up across a network? Dissimilar time and timezone settings?
> > >
> > >Kan, does this make any sense?
> > >
> > >Chaz
> >
> >
> >
> >
> >
> >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>[Non-text portions of this message have been removed]
>
>
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



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