You said previously:
| If you execute this prior to mounting a FAT file system, it will
| at least for dates in the current DST interval show correct file
| date/time.
Yes, this works about as well as the (inherently broken, as I now
realize) mount option I had proposed.
Edgar pointed out the real problem that I had missed: You need to
figure out if DST was active for each file based on its timestamp.
Duh. I feel pretty stupid now for not having realized that.
There doesn't seem to be an easy fix short of kludges such as embedding
the inverse DST calculation in the kernel. Another possibility is to
return the unmodified dates in unused fields in struct stat. There are
five unused fields in there right now. By passing both sets of dates
back, we support old programs and new, and don't introduce filsystem
dependence in libc. Old libc's could just pass the unmodified struct
stat on to the program and we'd have our current behavior. Newer libc's
could look at the new fields, calculate the correct GMT according
to the timezone setting, and fix up atime/mtime/ctime as appropriate.
Yet another option would be just to pass back the timezone that the
filesystem's dates correspond to in struct stat, and rely on userspace
to convert these to GMT. You'd pass the TZ as a mount option for
filesystems that care. That sounds like the overall cleanest to me,
although you'd have to pass TZ strings around which would be annoying.
It'd have the benefit that you could specify what timezone a given
HPFS/FAT/ISO9660 filesystem was created with, though, on a
filesystem-by-filesystem basis, and userspace would have a consistent
way to deal with all filesystems. GMT-based filesystems could leave
the fields NULL, and userspace would know it doesn't need to do anything
special.
Thoughts?
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/