From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1NDWwS-0002pe-FI for garchives@archives.gentoo.org; Thu, 26 Nov 2009 05:30:56 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 56D02E0912; Thu, 26 Nov 2009 05:30:41 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 1A5D9E0912 for ; Thu, 26 Nov 2009 05:30:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id A3CF567C42 for ; Thu, 26 Nov 2009 05:30:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 required=5.5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlhP5QU2NwmL for ; Thu, 26 Nov 2009 05:30:33 +0000 (UTC) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 6BBFF677DD for ; Thu, 26 Nov 2009 05:30:31 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NDWw1-00054Q-Jc for gentoo-dev@gentoo.org; Thu, 26 Nov 2009 06:30:29 +0100 Received: from ip68-231-21-207.ph.ph.cox.net ([68.231.21.207]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Nov 2009 06:30:29 +0100 Received: from 1i5t5.duncan by ip68-231-21-207.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Nov 2009 06:30:29 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: mtime preservation Date: Thu, 26 Nov 2009 05:30:05 +0000 (UTC) Message-ID: References: <20091120001820.7274bdf7@snowmobile> <4B07362D.2010108@gentoo.org> <7c612fc60911231049n4a51ddb0u30ae72d8ed93cdec@mail.gmail.com> <7c612fc60911251313i705a182as6cf50402c7829beb@mail.gmail.com> <20091125212718.5deb42f8@snowcone> <20091125221327.324e11fb@snowcone> <19213.46817.620937.656202@a1i15.kph.uni-mainz.de> <20091126001540.08a6e193@snowmobile> <4B0DD08D.8040505@gentoo.org> <20091126011427.GD23443@hrair> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-21-207.ph.ph.cox.net User-Agent: Pan/0.133 (House of Butterflies) Sender: news Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 3c9bc7dc-47d2-4575-9309-ddd7f690bad5 X-Archives-Hash: 12783e3c09350c505e35d036f8118123 Brian Harring posted on Wed, 25 Nov 2009 17:14:27 -0800 as excerpted: > On Wed, Nov 25, 2009 at 04:49:17PM -0800, Zac Medico wrote: >> Ciaran McCreesh wrote: >> > On Wed, 25 Nov 2009 23:59:45 +0100 >> > Ulrich Mueller wrote: >> >> Real examples would be issues like bugs 83877 [1] or 263387 [2]. >> >> Nothing that could be easily dismissed or worked around. Both issue= s >> >> are fixed with Portage since a long time. >> >=20 >> > Yes, those are examples of packages relying upon something that is >> > undefined behaviour, and that behaves differently depending upon the >> > Portage version you use. >> >=20 >> >> I don't know of any example where non-preservation of nanosecond >> >> timestamps would cause problems. >> >=20 >> > Not non-preservation. Partial and inconsistent corruption. >>=20 >> Wouldn't "loss of precision" be a more accurate description? Of the >> known packages which require timestamp preservation, do any of them us= e >> sub-second precision in their timestamp comparisons? >=20 > This discussion in generall is daft. No package can rely on nanonsecon= d > resolution for installation because the most common FS out there (ext3) > does *second* level resolution only. As such, I can pretty much > gurantee there is *zero* packages out there that require nanosecond > resolution for installation. One of the reasons I was asking for a bug number, was because there's two= =20 possible failure modes, and I was hoping reading them would clue me (or=20 at least those who are making the decisions here) in on which one=20 actually occurs. Your posts suggest a mode where subsecond times are always truncated. In= =20 such a case, there should be no issue. But it's also possible that times are compared as-is. If that's the=20 case, then there should be no issue on second-resolution filesystems=20 (such as ext3, in your example), because the filesystem would effectively= =20 truncate those, reducing to case-one, above. But on higher resolution=20 filesystems, there might very well be issues, due to the subtle double=20 resolution issue Ciaran pointed out, especially when compared against=20 renames where the mtimes were accurately preserved. Now it could well be that it's possible to turn case two into case one by= =20 adding a simple option to the the command line or the like. Or maybe=20 not. Again, that's why I wanted specific examples, so people could see=20 if that were tried or not, and I would have to write all this up and=20 possibly look like a moron if I'm getting it wrong, somehow. But since=20 the examples don't seem to be forthcoming, and in view of the IMO=20 legitimate point about such bugs very possibly being closed as=20 WORKSFORME, I guess I post this and hope someone can either explain that=20 I have it all wrong, or say definitively that such command-line time=20 truncation option workarounds are generally practical, or not, thus=20 potentially affecting the direction of the debate. --=20 Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman