Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-council
Navigation:
Lists: gentoo-council: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: Ulrich Mueller <ulm@g.o>
From: Ciaran McCreesh <ciaran.mccreesh@...>
Subject: Re: mtime preservation
Date: Thu, 19 Nov 2009 22:12:48 +0000
On Tue, 10 Nov 2009 08:07:17 +0100
Ulrich Mueller <ulm@g.o> wrote:
> ,----
> | The package manager must preserve modification times of regular
> files. | This includes files being compressed before merging.
> Exceptions to | this are:
> `----
> 
> Now we need to enumerate the exceptions:
> 
> ,----
> | * files newly created by the package manager,
> `----
> 
> This will cover splitdebug, for example. (And please don't tell me
> that the wording is flawed because the PM could save a file's contents
> in some buffer, then delete the file and create it newly. This would
> be as unreasonable as the rot-13 example.)

Funnily enough... objcopy does its own fancy things with utimes. Last
time I looked it wasn't sub-second aware, though.

> ,----
> | * binary object files being stripped of symbols.
> `----
>
> Anything else missing from above list?

man pages, info pages, things covered by ecompress, arbitrary
documentation, any source code file, probably some others.

> > (thus preventing reasonable-looking future changes), [...]
> 
> I don't get the point here. For any future change not covered by the
> list of exceptions, the PM would have to preserve mtime, in spite of
> modifying the file. Why would this prevent doing the change?

Preserving mtime isn't always the right thing to do, though. If the
package manager does something that would invalidate caches, you don't
want it to do so in a way that won't be noticed.

Also, back on the subject of sub-second resolution mtimes... Python
doesn't support them properly thanks to some utter brain damage from
its designers [1]. Files will end up with corrupted sub-second mtimes if
Python is used to set those times, which can again lead to broken
caches. But since not everything Portage merges does use Python to set
sub-second mtimes, this will result in any cache that starts looking at
sub-second resolution mtimes (which will happen -- POSIX considers the
non-sub-second functions deprecated) seeing a mix of valid and subtly
corrupted timestamps.

I honestly don't think we should be going anywhere with this until
Portage is using a mechanism that guarantees correct sub-second
resolution preservation in all cases.

[1]: http://ciaranm.wordpress.com/2009/11/15/this-week-in-python-stupidity-os-stat-os-utime-and-sub-second-timestamps/

-- 
Ciaran McCreesh
Attachment:
signature.asc (PGP signature)
Replies:
Re: mtime preservation
-- Ulrich Mueller
Re: mtime preservation
-- Denis Dupeyron
References:
Agenda (draft) for November meeting 2009-11-09
-- Ulrich Mueller
Re: Agenda (draft) for November meeting 2009-11-09
-- Ciaran McCreesh
mtime preservation (was: Agenda (draft) for November meeting 2009-11-09)
-- Ulrich Mueller
Re: mtime preservation (was: Agenda (draft) for November meeting 2009-11-09)
-- Ciaran McCreesh
Re: mtime preservation
-- Ulrich Mueller
Re: Re: mtime preservation
-- Ciaran McCreesh
Re: Re: mtime preservation
-- Denis Dupeyron
Re: Re: mtime preservation
-- Ciaran McCreesh
Re: mtime preservation
-- Ulrich Mueller
Navigation:
Lists: gentoo-council: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: mtime preservation
Next by thread:
Re: mtime preservation
Previous by date:
Re: mtime preservation
Next by date:
Re: mtime preservation


Updated Nov 13, 2011

Summary: Archive of the gentoo-council mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.