Date: Fri, 30 Jan 2009 01:43:35 -0800 From: Maxim Sobolev <sobomax@FreeBSD.org> To: Tim Kientzle <kientzle@FreeBSD.org> Cc: "'current@FreeBSD.org'" <current@FreeBSD.org> Subject: Re: RFC: Change mtree nsec handling? Message-ID: <4982CBC7.5050102@FreeBSD.org> In-Reply-To: <49829D49.10306@freebsd.org> References: <49829D49.10306@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Tim Kientzle wrote: > In looking at interoperability between libarchive's > 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. > > Basically, mtree is printing (and reading) the time > as whole seconds and nanoseconds separated by a period, > which 90% of the time is the same as a decimal > floating-point number of seconds, but not the other > 10% of the time. This is not documented in mtree.8. > I was quite surprised by it. > > The attached patch changes this to use a more conventional > notation (although the patch could use a little more tweaking > to handle >9 digits after the decimal point). > > Any concerns about this? Given the age of mtree(8) I guess there are lot of existing mtree specs out there who rely on this behavior. Therefore, IMHO the right thing to do would be either note this in the documentation and let it be, or mark "time" keyword as depreciated and add some new keyword for example "timestamp". The new keyword will be generated by default by mtree(8) instead of "time" and will do the right thing. Then, in few years from now "time" could be deorbited. -Maxim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4982CBC7.5050102>