|
Removeable HD and pre-Daylight Savings timestamp?!
Let me explain, that was incoherent even for me (title length limitations.)
I have a removeable hard drive (a Ximeta 80 gig that connects using USB 2 or Ethernet.) My procedure with this drive is to use "Total Commander" to synchronize some directories on the hard drive with those on my desktop at home and at my office. The synchronize operation is sensitive to similarly named files in the same directory paths on each of the two drives that have different sizes, or... timestamps.
I syncd everything pre-daylight savings time changeover this past weekend. Now, you do see where this is going, don't you?
I tried to sync Monday morning, and every file that had already existed on the removeable hard drive was stamped exactly 1 hour older than the corresponding file on the desktop PC. So TC wanted to needlessly copy all files from the desktop to the removeable.
It appears that the file timestamp is relative to savings time (and maybe even the time zone, but I haven't tried that yet). Or maybe there's something else going on. "Reasonable" behavior would be to see all files on the removeable display time stamps that were adjusted for DST.
What does one do to correct this problem other than copying everything?
The Ximeta is preconfigured to use FAT32, and my desktop is Windows 2000 Pro using NTFS.
This seems like a significant problem, because it could affect virtually any backup procedure. A newsgroup search indicates that this is a known problem and is specific to NTFS (which adjusts all file timestamps as returned by the API) when files are mirrored to non NTFS volumes. Which describes most backup technologies.
Any ideas?
Thanks.
Bored Bystander
Wednesday, April 7, 2004
I just checked - changing the time zone on the computer changes the represented file creation time in explorer, which says to me that at least NTFS keeps either the UTC or time zone in the file properties.
DST is handled by changing the time zone - on the east coast, +5R (EST) becomes +4Q (EDT).
So it sounds to me like the capabilities are there and your software isn't observing them.
Philo
Philo
Wednesday, April 7, 2004
Does this help explain things?
http://weblogs.asp.net/oldnewthing/archive/2004/02/26/80492.aspx
R1ch
Wednesday, April 7, 2004
The weblog entry explained the situation. Basically, it is the file system to blame. FAT time stamps files by local time. NTFS stamps files by UTC (aka GMT). The NTFS files "jumped ahead" because the OS reports the timestamps adjusted by the current savings time.
The FAT files are timestamped "wrong", by simple local time, never with any adjustment.
Ok, my question is answered. Kind of what I thought was going on.
Sheesh.
Bored Bystander
Wednesday, April 7, 2004
As an aside, that weblog is one of the few that I've found worth reading regularly - it explains so many of the idiosyncracies in Windows and why things work the way they do (or don't).
r1ch
Wednesday, April 7, 2004
By the way, if the file systems are NTFS all around, then it sounds like this is a pretty significant bug. The date and time of the files should NOT have changed.
You didn't change time zones. You moved to daylight savings time. If you'd made the change on March 30th at 7am (local time), the fact that you are NOW in daylight savings time is irrelevant.
I guess the presumption is that the removeable drive is FAT instead of NTFS.
Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, April 7, 2004
Nevermind, I see now that I missed the file system desciptions in the original post. Ignore me. :)
Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, April 7, 2004
FWIW, I use FileSync for exactly this and it has an "ignore 1 hr time difference" option to deal with it.
www.FileWare.com -- I have no affiliation.
sgf
Wednesday, April 7, 2004
"By the way, if the file systems are NTFS all around, then it sounds like this is a pretty significant bug. The date and time of the files should NOT have changed.
You didn't change time zones. You moved to daylight savings time. If you'd made the change on March 30th at 7am (local time), the fact that you are NOW in daylight savings time is irrelevant."
You could of course read the whole thread first, where I explained that as far as anyone who does business keeping time is concerned, you have in fact changed time zones - the East Coast is normally +5 EST. Right now we're +4 EDT. Those three letters on the end are the time zone - you may have noticed they change.
Or, practically speaking - you save a file at 1:30 AM EDT. At 2 AM you set your clock back to EST. At 1:20 AM EST you save the file again.
Is it newer? Do you want the file system to understand that it's newer?
Philo
Philo
Wednesday, April 7, 2004
"You could of course read the whole thread first..."
Says the kettle to the pot. ;)
Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, April 7, 2004
Not at all - you did not retract the part I quoted, as far as I could tell. Does the fact that the "bug" was caused by mismatched file systems change your opinion about time stamps being time zone dependent, including DST?
;-)
Philo
Philo
Thursday, April 8, 2004
I stand by my statement. To clarify, since I think you're wrong:
The 1 hour a year of time "uncertainty" is precisely why the date/times are stored in GMT in the first place. Yes, it would be ABSOLUTELY, UNEQUIVOCALLY wrong to unilaterally shift the time presentation of the DIR command by one hour during the hour of uncertainty (and it wouldn't help, since it just moves the problem an hour back, and you put yourself in a neverending pattern of trying to catch up).
The problem is that DIR doesn't show the time with enough precision; if you were that worried about DIR's display accuracy, then you should be lobbying for display of "EST" vs. "EDT" on the times instead of moving them an hour. That would resolve that hour of inaccuracy.
Just because DIR shows the times in local time for the user as a convenience, doesn't mean that we as coders should be using that local time for the determination of "newer" or "older". Your straw man is on fire. :-p
Brad Wilson (dotnetguy.techieswithcats.com)
Thursday, April 8, 2004
And, to be clear about file system mis-matches: I didn't say anything about that. Yes, FAT32 is broken. Duh. Any geek should know that.
Brad Wilson (dotnetguy.techieswithcats.com)
Thursday, April 8, 2004
 Recent Topics
Fog Creek Home
| 
