>> I meant what I said, especially "something like" - as in "tell
>> the mount command the relevant timezone by whatever means the
>> author thereof implements."
> Yeah -- I was just making sure you weren't intending to pass the
> string "MST" into the kernel for translation. *Not* that I think
> *you* are that stupid, of course, but some people on this thread
> have suggested similar things.
Personally, I'd sooner see the mount(8) command accept the timezone
name and perform the translation, simply because of the fact that
different countries have different interpretations of - and + when it
comes to specifying timezone offsets - some specify the offset as
local - GMT and others as GMT - local !!!
However, the actual timezone name would be meaningless in the kernel.
>> I would image it could be implemented by adding a signed word
>> field to the private mount data for the affected partitions, and
>> have that store the offset in minutes relating to that
>> partition. It would need to be able to handle values between
>> -750 and +750
> And don't forget that it needs to be affected by "-o remount".
If it was, that would be part of the internal logic of the mount(8)
command, and not part of the kernel itself. Memory says that the
"-o remount" option only tweaks existing values, so if it said...
mount -o remount,tz=MDT /win95
...then yes, it would be expected to tweak the partition's time offset
field, but if it didn't include such an option, it would have no
reason to do so.
As far as the driver is concerned, it would work as follows:
1. When a stat() call arrives for a file, it looks up the
file's details and fills in the stat() structure, then
tweaks the time fields in that structure by subtracting
the stored offset from each one.
2. When it has reason to update a time on the FAT partition,
it tweaks the stored time by adding the stored offset to
the value to be stored.
This basically implies that as far as the rest of the kernel is
concerned, the driver always uses and provides GMT, which I believe to
be the assumption that's made at the moment by the rest of the kernel.
It's just that at the moment, the said assumption is flawed.
As far as the driver is concerned, it is handling a drive that stores
times based on whatever time offset the relevant field has when it
writes the file, and the tweaks to implement that shouldnae be hard.
Lemme have a look...
> That way a cron job can keep your legacy filesystem displaying
> data in the right legacy way even when you don't reboot twice a
> year.
If I can avoid it, I don't reboot even once a year.
> (In which case you probably don't dual-boot and may well not
> need FAT at all, but that's beside the point.)
There are reasons other than running MacroHard's OS's on that machine
for using FAT based file systems on floppies, one obvious one being
that the format is common to many different operating systems. As an
example, if I wish to download any large files, I take one or two VFAT
formatted Zip-100's into the local university and download over their
internet links. Since their systems don't run Linux (they dual-boot
either WinNT or Solaris), VFAT makes the best choice.
Best wishes from Riley.
* Copyright (C) 1999, Memory Alpha Systems.
* All rights and wrongs reserved.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* http://www.memalpha.cx/Linux/Kernel/
-
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/