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 <[email protected]> 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
