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 |