From owner-freebsd-current@FreeBSD.ORG Fri Jan 30 11:38:33 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 3D0011065674; Fri, 30 Jan 2009 11:38:33 +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 04FD28FC1F; Fri, 30 Jan 2009 11:38:32 +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 n0UBcV5v008194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 03:38:32 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <4982E698.1090204@FreeBSD.org> Date: Fri, 30 Jan 2009 03:38:00 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Peter Jeremy References: <49829D49.10306@freebsd.org> <4982CBC7.5050102@FreeBSD.org> <20090130112307.GJ1755@server.vk2pj.dyndns.org> In-Reply-To: <20090130112307.GJ1755@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , "'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 11:38:33 -0000 Peter Jeremy wrote: > On 2009-Jan-30 01:43:35 -0800, Maxim Sobolev 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