xp xcopy /d copies all after a clock set

[Guest]

Archived from groups: microsoft.public.windowsxp.general (More info?)

I use a batch file containing a few XCOPY /D lines to copy between
networked computers, to backup a few directories containing many files.
The /D says "dont copy unless the file has a newer date/time stamp".
Normally this works great, and just copies the few newer files.

However if the destination computer has just set the clock time, then
the /D is not honored, and every file is copied regardless of date/time
(it is not about a few minutes, it is ALL files, going back months and
years). I'm not sure how long this effect lasts, next boot or next day,
but in a day or two, then it works fine again.

Is this a known situation? Any fix for it?

XP SP2 + all the current patches.
Both are Asus AMD motherboards.

 

[stivk]

Dear Anonymous,

I have had a similar but not identical experience. I studied and researched and pondered, and eventually stumbled across program called AttributeMagic which shows the date/time modified attribute of files to hh:mm:ss rather than just hh:mm as is the case in Windows Explorer.

I found that after XCOPY had finished the time stamp of the target file had advanced (by 2 seconds in my case) from that of the source file from which it was copied.

I cant imagine why the second amount is different, but it is consistent, and I wonder if in your case the time on the target file has retreated by a quantum (thank you James Bond). This would cause every subsequent execution of XCOPY to think that the source needed to be backed again (and again).

This is all speculation and I recommend you find yourself a way to display the time last modified time down to the second to confirm or dispel my theory.

If this is true, I don't know what the fix is.

Kind regards,
Steve.

 

[stivk]

I have nutted out my prob. Check if you are XCOPYing from an NTFS drive to a FAT32 drive. If so, format the FAT32 as NTFS (or the NTFS as FAT32) and I think the prob will go away, at least it did for me.

I read that FAT32 drives can only store the sec part of the time to within 2 seconds, and therefore rounding occurs (if this is not true then everything that follows is flawed). If this IS true, and the target time is rounded down, then next time XCOPY runs the time discrepancy affects its behavior as you have witnessed.

You don't see the time diff in Windows Explorer because the time is only shown to the minute. Argh!