| 1 |
Brian Harring posted on Wed, 25 Nov 2009 17:14:27 -0800 as excerpted: |
| 2 |
|
| 3 |
> On Wed, Nov 25, 2009 at 04:49:17PM -0800, Zac Medico wrote: |
| 4 |
>> Ciaran McCreesh wrote: |
| 5 |
>> > On Wed, 25 Nov 2009 23:59:45 +0100 |
| 6 |
>> > Ulrich Mueller <ulm@g.o> wrote: |
| 7 |
>> >> Real examples would be issues like bugs 83877 [1] or 263387 [2]. |
| 8 |
>> >> Nothing that could be easily dismissed or worked around. Both issues |
| 9 |
>> >> are fixed with Portage since a long time. |
| 10 |
>> > |
| 11 |
>> > Yes, those are examples of packages relying upon something that is |
| 12 |
>> > undefined behaviour, and that behaves differently depending upon the |
| 13 |
>> > Portage version you use. |
| 14 |
>> > |
| 15 |
>> >> I don't know of any example where non-preservation of nanosecond |
| 16 |
>> >> timestamps would cause problems. |
| 17 |
>> > |
| 18 |
>> > Not non-preservation. Partial and inconsistent corruption. |
| 19 |
>> |
| 20 |
>> Wouldn't "loss of precision" be a more accurate description? Of the |
| 21 |
>> known packages which require timestamp preservation, do any of them use |
| 22 |
>> sub-second precision in their timestamp comparisons? |
| 23 |
> |
| 24 |
> This discussion in generall is daft. No package can rely on nanonsecond |
| 25 |
> resolution for installation because the most common FS out there (ext3) |
| 26 |
> does *second* level resolution only. As such, I can pretty much |
| 27 |
> gurantee there is *zero* packages out there that require nanosecond |
| 28 |
> resolution for installation. |
| 29 |
|
| 30 |
One of the reasons I was asking for a bug number, was because there's two |
| 31 |
possible failure modes, and I was hoping reading them would clue me (or |
| 32 |
at least those who are making the decisions here) in on which one |
| 33 |
actually occurs. |
| 34 |
|
| 35 |
Your posts suggest a mode where subsecond times are always truncated. In |
| 36 |
such a case, there should be no issue. |
| 37 |
|
| 38 |
But it's also possible that times are compared as-is. If that's the |
| 39 |
case, then there should be no issue on second-resolution filesystems |
| 40 |
(such as ext3, in your example), because the filesystem would effectively |
| 41 |
truncate those, reducing to case-one, above. But on higher resolution |
| 42 |
filesystems, there might very well be issues, due to the subtle double |
| 43 |
resolution issue Ciaran pointed out, especially when compared against |
| 44 |
renames where the mtimes were accurately preserved. |
| 45 |
|
| 46 |
Now it could well be that it's possible to turn case two into case one by |
| 47 |
adding a simple option to the the command line or the like. Or maybe |
| 48 |
not. Again, that's why I wanted specific examples, so people could see |
| 49 |
if that were tried or not, and I would have to write all this up and |
| 50 |
possibly look like a moron if I'm getting it wrong, somehow. But since |
| 51 |
the examples don't seem to be forthcoming, and in view of the IMO |
| 52 |
legitimate point about such bugs very possibly being closed as |
| 53 |
WORKSFORME, I guess I post this and hope someone can either explain that |
| 54 |
I have it all wrong, or say definitively that such command-line time |
| 55 |
truncation option workarounds are generally practical, or not, thus |
| 56 |
potentially affecting the direction of the debate. |
| 57 |
|
| 58 |
-- |
| 59 |
Duncan - List replies preferred. No HTML msgs. |
| 60 |
"Every nonfree program has a lord, a master -- |
| 61 |
and if you use the program, he is your master." Richard Stallman |
Archives