Poul-Henning Kamp wrote: > In message <49829D49.10306_at_freebsd.org>, Tim Kientzle writes: > >>mtree support and the mtree(8) program, I found >>that mtree formats timestamps rather strangely. >> >>For example, a timestamp of 1233295862.000001 >>(1233295682 seconds and 1000 nanoseconds) >>will be printed like this by mtree: >> time=1233295862.1000 >>Unsurprisingly, the mtree parsing works the same >>way in reverse. > >>_at__at_ -258,6 +259,8 _at__at_ >> val = ep + 1; >> ip->st_mtimespec.tv_nsec >> = strtoul(val, &ep, 10); >>+ for (i = ep - val; i < 9; ++i) >>+ ip->st_mtimespec.tv_nsec *= 10; > > > Why is this bit needed ? > This is the part that converts 1233295862.000001 into 1000 nanoseconds (instead of 1 nanosecond). Two reasons: 1) Documentation. It's much easier to document "decimal seconds" than "period followed nine digits representing the number of nanoseconds past the whole second." 2) Interoperability. I originally noticed this testing other mtree-producing code against our mtree implementation. For example, since FreeBSD filesystems never (?) store higher resolution than microseconds, there's really no reason to write more than 6 digits after the decimal point. It seems a tad naive to assume that everyone will always write 9 digits. I can leave this out for a cycle if there's real concern. Fractional seconds occur so rarely on FreeBSD systems (to my knowledge, the kernel never spontaneously generates them so they can only be created by tools like touch that explicitly call utimes()) that I didn't think this would affect any real applications. But if I'm wrong.... <shrug> TimReceived on Fri Jan 30 2009 - 16:05:28 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:41 UTC