| 1 |
Ciaran McCreesh wrote: |
| 2 |
> On Wed, 04 Nov 2009 13:12:37 -0800 |
| 3 |
> Zac Medico <zmedico@g.o> wrote: |
| 4 |
>>> So far as I can see, if they're fully supported on both filesystems, |
| 5 |
>>> Portage sometimes preserves nanosecond-resolution timestamps and |
| 6 |
>>> sometimes doesn't. So, requiring nanosecond-resolution timestamp |
| 7 |
>>> preservation where possible will need Portage changes. |
| 8 |
>> I think it always preserves them, as long as you have at least |
| 9 |
>> python-2.5 since that is required for floating-point mtime support. |
| 10 |
> |
| 11 |
> Mm, I can't see the code for that. So far as I can see, for the |
| 12 |
> non-fast case you're using stat.st_mtime and os.utime, which assuming |
| 13 |
> they correspond to the POSIX things of the same name, are |
| 14 |
> second-resolution. What am I missing? |
| 15 |
|
| 16 |
Ah, I guess you're right. The documentation led me to believe that |
| 17 |
os.utime would provide nanosecond-resolution on platforms that |
| 18 |
support it, but a simple test case seems to indicate that it does not. |
| 19 |
-- |
| 20 |
Thanks, |
| 21 |
Zac |
Archives