Changesets 381 and on add time field updating to tux3 and tux3fuse: http://tux3.org/tux3
This can be verified by the fact that ls -l now shows correct dates for a fuse-mounted Tux3 filesystem, and even has subsecond resolution. Commands to test this: make && make mkfs && make defuse Then in another terminal: sudo su cd /tmp && touch test/foo && ls -l test or stat test/foo (The "make defuse" target mounts a test filesystem on /tmp/test. You need to be root to work on it, because permissions are not implemented properly yet.) Tux3 times are represented in fixed point fractions, as opposed to the more common representation of separate integer seconds and decimal fraction fields as used by libc and most or everywhere in kernel. That never made sense to me, I really think it would have been better if decimal fractions had died along with BCD and Nixie tubes. Fixed point fractions are altogether better for arithmetic and verifiable code. At the moment the format is 32.32, that is, 32 bits of integer seconds and 32 bits of binary fraction for in-memory "tuxtime". But that is probably not quite right because it fails to avoid the 2037 overflow problem. There are a few ways we could deal with that. Probably the easiest is just to give another bit or two to the integer field, for example, 33.31 format, which leaves us with the year 2015 problem, or 34.30 which yields the 2241 problem, long after most of use will not care about it very much any more. Or another way of looking at it is, it should be enough time to come up with a backward compatible version that has greater date range. Another way to to extend the date range is to assume unsigned instead of signed date values internal to Tux3. This by itself gets us to 2015 with 32.32 format, at the expense of not being able to represent dates before 1969. Does anybody care? Another option is to represent dates relative to the creation date of the filesystem, and the creation date can have higher range. These are all just slight tweaks, and we have lots of time to fiddle with this. Suggestions welcome. Dates are stored in inode table blocks in 32.16 format, sacrificing some precision to save two bytes per date field. Is it worth it? I can't say for sure, but I think it is and this is easy to change if I turn out to be wrong. A 32.16 field gives a resolution of 1/(2**16) seconds. If we take away a bit for higher range, that is 1/(2**15) or better than one part in thirty thousand. My feeling is, if somebody needs higher resolution than that for a filesystem timestamp, they are probably doing something wrong. Regards, Daniel _______________________________________________ Tux3 mailing list [email protected] http://tux3.org/cgi-bin/mailman/listinfo/tux3
