[<<]Message[>>] [<<]Author[>>] [<<]Subject[>>] [<<]Thread
Number : 3178 Date : 2002-12-02 Author : Chaz Cone Subject : Re: Suddenly frustrated, then baffled, then... Size(KB) : 7
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]
This message if part of XXCOPY's message Archive. The archive contains all the messages posted at Yahoo!Groups: XXCOPY.