| 1 |
On Thu, Nov 26, 2009 at 12:35:53PM +0000, David Leverton wrote: |
| 2 |
> 2009/11/26 Brian Harring <ferringb@×××××.com>: |
| 3 |
> > It's an academic discussion, and pointless. We don't mandate the |
| 4 |
> > filesystems PMS implementations are run on- as such we cannot make a |
| 5 |
> > gurantee to ebuilds that nanosecond resolution is available. It's |
| 6 |
> > daft to encode in the spec NS resolution when it's essentially |
| 7 |
> > impossible to gurantee it |
| 8 |
> |
| 9 |
> If we're not going to insist on preserving nanoseconds as far as |
| 10 |
> possible, then package managers should be required to explcitly clear |
| 11 |
> the nanoseconds part. |
| 12 |
|
| 13 |
I'd had the same thought actually. If folks really consider it to be |
| 14 |
needed, then jam it in as far as I'm concerned. It has the potential |
| 15 |
to remove a heisenbug or two. |
| 16 |
|
| 17 |
Presuming I'm reading posixmodule correctly from the python source, |
| 18 |
pkgcore already does second truncation (reliance on utime) and portage |
| 19 |
does it whenever movefile is invoked- any direct mv invocations |
| 20 |
obviously do not however. |
| 21 |
|
| 22 |
Basically, if stat_float_mtimes is False (the case for all portage |
| 23 |
context and most of pkgcore context), os.utime auto truncates to |
| 24 |
second precision. |
| 25 |
|
| 26 |
~harring |
Archives