My point. That is the *only* reason anyone would use FAT on Linux --
to interoperate with legacy systems.
> > 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.
Check it yourself. But what seems to be happening, according to my
limited perusal, is that if you created a file in NT4 at 3:00 AM in
Central Daylight Time (GMT-0500) and put it on a FAT floppy, the time
stored on the floppy is 3:00 AM, no particular timezone. Then if you
do a `dir' on that floppy a couple months later in Central Standard
Time (GMT-0600), it will still say 3:00 AM. FAT does not care about
time changes and it assumes everyone who will ever have access to a
particular file will be in the same time zone.
On an ext2 filesystem in Linux, on the other hand, the timestamp stored
would have been 8:00 AM, i.e. UTC; `ls' converts this to 3:00 AM
because it knows about DST conversions and when to do them and when not
to, thanks to libc functions specializing in this. If you set TZ to
something else, then do the `ls', it will convert the UTC value to
whatever else you wanted.
So the thing to do for Linux FAT, in order to show the same timestamps
as NT4 does (AFAICT), is to convert from UTC to local when writing and
from local to UTC when reading. "local" means some constant offset as
fed in by the init scripts. (These init scripts should use discretion
in choosing the local offset -- preferably whatever DOS machines in the
immediate vicinity are using ... it's not a very multi-user concept but
neither is FAT and it may be the best we can do.) Yes, that's
*contant* offset -- do not attempt to correct for DST or non-DST *when
the file was written*. The only time to change that offset is when DST
*itself* comes or goes.
I do not know whether FAT already has this behavior on Linux. My
system's FAT seems to report times in UTC but I don't know if there's a
way to add the "local" offset I describe above.
> 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.
With my scheme, you won't (which is why I noted that it would break
normal Unix semantics), but at least the file will have been stored the
same way on disk as it would have been in your legacy system. If you
want complete interoperability, you will need to define a non-DST-able
time zone and manually change it twice a year. (Two cron jobs that
symlink ~/.bashrc-tz -> .bashrc-dst or ~/.bashrc-tz -> .bashrc-nodst
might be the easiest way. Then .bashrc does "source ~/.bashrc-tz".)
> So do the "legacy systems" meet these criteria?
No. That's the problem. It comes back to: if we don't bother with
compatibility with the legacy systems, there are a lot of ways to make
up for some of the deficiencies in FAT. But then again, if we don't
bother with compatibility with the legacy systems, we don't *need* FAT.
-- Peter Samuelson <sampo.creighton.edu!psamuels>- 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/