[Rpm-metadata] Why does createrepo -C use ctime, not mtime?
vogel at folz.de
Wed Apr 7 17:16:00 UTC 2010
On Wed, Apr 07, 2010 at 12:42:28PM -0400, Seth Vidal wrote:
> On Wed, 7 Apr 2010, Seth Vidal wrote:
> >On Wed, 7 Apr 2010, Robert Vogelgesang wrote:
> >>Hello developers,
> >>currently, I'm investigating an issue with "createrepo --update -C"
> >>when run by "cobbler reposync", and found in createrepo's source
> >>that the -C option is based on Python's os.path.getctime(), i. e. the
> >>time of the last status change on *nix hosts (ctime).
> >>As of version 18.104.22.168, "cobbler reposync" chown's and chmod's all
> >>files in a repo on each run, changing the ctime of all files in the
> >>repo; I think this is a bug in itself, but nonetheless I'd expect
> >>that mtime is used by createrepo when checking for changed files.
> >>createrepo's variable which holds the reference timestamp,
> >>self.mdtimestamp in class MetaDataConfig, seems to indicate that mtime
> >>should be, or even was historically used. So, is there any special
> >>reason why this is based on ctime and not mtime? I've searched
> >>createrepo's source, and http://createrepo.baseurl.org/, but found
> >>no answer.
> >>Can you shed some light on this, please?
> >You have to search pretty far back.
> >here is where the original -C behavior comes from:
ahh, thank you.
> And looking back further - the original behavior was getmtime() but Pete
> found some problems with the reliability of mtime() for the check.
> I don't remember the _why_ there, though.
As far as I can see in the mailing list archive, the timestamp check
initially used the timestamp of the repo directory instead of the
repomd.xml file, as now in the current version. Could that be part
of the reason? I. e., maybe the mtime issues are fixed by the
change to check repomd.xml instead of the repo directory?
> Rpm-metadata mailing list
> Rpm-metadata at lists.baseurl.org
More information about the Rpm-metadata