[gentoo-dev] Re: mtime preservation

[Duncan <1i5t5.duncan@cox.net>]

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 <ulm@gentoo.org> wrote:
>> >> Real examples would be issues like bugs 83877 [1] or 263387 [2].
>> >> Nothing that could be easily dismissed or worked around. Both issues
>> >> are fixed with Portage since a long time.
>> > 
>> > Yes, those are examples of packages relying upon something that is
>> > undefined behaviour, and that behaves differently depending upon the
>> > Portage version you use.
>> > 
>> >> I don't know of any example where non-preservation of nanosecond
>> >> timestamps would cause problems.
>> > 
>> > Not non-preservation. Partial and inconsistent corruption.
>> 
>> Wouldn't "loss of precision" be a more accurate description? Of the
>> known packages which require timestamp preservation, do any of them use
>> sub-second precision in their timestamp comparisons?
> 
> This discussion in generall is daft.  No package can rely on nanonsecond
> 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 
possible failure modes, and I was hoping reading them would clue me (or 
at least those who are making the decisions here) in on which one 
actually occurs.

Your posts suggest a mode where subsecond times are always truncated.  In 
such a case, there should be no issue.

But it's also possible that times are compared as-is.  If that's the 
case, then there should be no issue on second-resolution filesystems 
(such as ext3, in your example), because the filesystem would effectively 
truncate those, reducing to case-one, above.  But on higher resolution 
filesystems, there might very well be issues, due to the subtle double 
resolution issue Ciaran pointed out, especially when compared against 
renames where the mtimes were accurately preserved.

Now it could well be that it's possible to turn case two into case one by 
adding a simple option to the the command line or the like.  Or maybe 
not.  Again, that's why I wanted specific examples, so people could see 
if that were tried or not, and I would have to write all this up and 
possibly look like a moron if I'm getting it wrong, somehow.  But since 
the examples don't seem to be forthcoming, and in view of the IMO 
legitimate point about such bugs very possibly being closed as 
WORKSFORME, I guess I post this and hope someone can either explain that 
I have it all wrong, or say definitively that such command-line time 
truncation option workarounds are generally practical, or not, thus 
potentially affecting the direction of the debate.

-- 
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