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