Compatability and active interoperability. I use FAT to communicate
with my Windows/DOS half because sadly there are some things I still
need to do over there.
Note that ISO9660 seems to have a similar DST issue, from what I
recall, and it's a standard that isn't going away until the mountains
of existing CD-ROMs start decomposing. :-)
(HPFS also has a similar issue apparently, although I don't view HPFS
as being as much of an issue. At the risk of offending OS/2 users,
lets face it -- there aren't nearly as many HPFS disks out there as
there are FAT or ISO9660 disks, by a couple orders of magnitude.)
| So, what do legacy systems do?
|
| Extremely limited testing with NT4 vs. mtools suggests that the legacy
| system I have seems to use the *current* DST setting -- or, more to the
| point, reads and writes timestamps in reference to *current* wall clock
| time, *not* correcting for whether DST was in effect at the file's
| mtime.
So, the time displayed for a file I created two months ago (while DST
was active) will be different since DST is now inactive? That makes no
sense. The issue is not really about files being updated right now --
rather it's more about correctly representing the date/time stamps of
all files on the filesystem.
>From what I understand, the current wall-clock time (taking all
DST conversions into account) is what's used for marking the file's
time on the disk for FAT filesystems. So, on a system which uses GMT
for all date stamps, the conversion from the filesystem's recorded time
to GMT needs to take into account whether or not DST was in effect at
time specified by the date stamp, since GMT never does DST.
Note that user-space takes the GMT time and does the reverse: It
determines what the local wall-clock time was for the given date, again
accounting for whether DST was active at that time. It only does
this for display purposes, though. Internally, time_t is always in
GMT.
These conversions aren't an issue on "Legacy systems" such as
Windows/DOS, since the probably don't make the intermediate jump to
GMT. As long as the whole system operates in Local Time, no
conversions are necessary. The reason this is a problem on Linux is
the fact that the whole system runs in GMT and converts to local time
only on display. A filesystem whose timebase is local-time throws
a monkeywrench in the works, since there's no fixed offset that can
be applied to correct the times if DST can happen.
| So Linux FAT should do the same. It breaks Unix semantics, but FAT
| never was about Unix semantics in the first place.
Linux FAT should update timestamps to the current wall-clock time.
Also, the timestamp reported for a file should not change depending on
what day I look at it, if I haven't changed the file. For instance, if
I create a file while DST is active, and then I look at it when DST is
inactive, I should see the same time-stamp as I did back when DST was
active, not an hour different.
So do the "legacy systems" meet these criteria?
Regards,
--Joe
-- -- Joseph Zbiciak | "Never worry about the theory -- -- j-zbiciak1@ti.com | as long as the machinery -- -- #include <std_disc.h> | does what it is supposed to do." -- -- Texas Instruments, Dallas | -- Heinlein --- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/