From owner-freebsd-current@FreeBSD.ORG Fri Jan 30 09:44:07 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C65AB10656F6 for ; Fri, 30 Jan 2009 09:44:07 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 8C4498FC2F for ; Fri, 30 Jan 2009 09:44:07 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id n0U9i5CA002072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 01:44:06 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <4982CBC7.5050102@FreeBSD.org> Date: Fri, 30 Jan 2009 01:43:35 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Tim Kientzle References: <49829D49.10306@freebsd.org> In-Reply-To: <49829D49.10306@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'current@FreeBSD.org'" Subject: Re: RFC: Change mtree nsec handling? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2009 09:44:10 -0000 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