Date: Fri, 30 Jan 2009 03:38:00 -0800 From: Maxim Sobolev <sobomax@FreeBSD.org> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: Tim Kientzle <kientzle@FreeBSD.org>, "'current@FreeBSD.org'" <current@FreeBSD.org> Subject: Re: RFC: Change mtree nsec handling? Message-ID: <4982E698.1090204@FreeBSD.org> In-Reply-To: <20090130112307.GJ1755@server.vk2pj.dyndns.org> References: <49829D49.10306@freebsd.org> <4982CBC7.5050102@FreeBSD.org> <20090130112307.GJ1755@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy wrote: > On 2009-Jan-30 01:43:35 -0800, Maxim Sobolev <sobomax@freebsd.org> wrote: >> Tim Kientzle wrote: >>> 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. >> Given the age of mtree(8) I guess there are lot of existing mtree specs >> out there who rely on this behavior. > > The existing code to read nanoseconds will handle either the old > format or a %09d format (the for() loop that Tim added is unnecessary) > so existing specs won't have a problem. I think adding leading zeroes > is the correct way to proceed. My point is that it would not restore correct timestamp, not that it would not read it. The 1233295862.000001 before change would become 1233295862.1000 after. I don't know how important is it, but I can imagine some applications where it could be an issue (e.g. incremental backup). -Maxim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4982E698.1090204>