fedora-infrastructure

#6350 fullfiletimelist* files seem to contain wrong timestamps
Closed: Fixed Opened by bellet.

Closed: Fixed
Reopen Issue

For example, in fedora-secondary:
$ grep updates/22/aarch64/s/spice-gtk3-0.30-1.fc22.aarch64.rpm fullfiletimelist-fedora-secondary
1504650164 f 56156 updates/22/aarch64/s/spice-gtk3-0.30-1.fc22.aarch64.rpm
$ date -d '1970-01-01 UTC 1504650164 seconds'
Wed Sep 6 00:22:44 CEST 2017
ls -l updates/22/aarch64/s/spice-gtk3-0.30-1.fc22.aarch64.rpm
-rw-r--r-- 1 bellet bellet 56156 Oct 10 2015 updates/22/aarch64/s/spice-gtk3-0.30-1.fc22.aarch64.rpm

But also with more recent files, in fedora-enchilada:

$ ls -l linux/development/rawhide/Everything/source/tree/Packages/f/fakeroot-1.22-1.fc28.src.rpm
-rw-r--r-- 1 bellet bellet 358345 Sep 8 13:39 linux/development/rawhide/Everything/source/tree/Packages/f/fakeroot-1.22-1.fc28.src.rpm
$ grep linux/development/rawhide/Everything/source/tree/Packages/f/fakeroot-1.22-1.fc28.src.rpm fulltime
1504974635 f 358345 linux/development/rawhide/Everything/source/tree/Packages/f/fakeroot-1.22-1.fc28.src.rpm
$ date -d '1970-01-01 UTC 1504974635 seconds'
Sat Sep 9 18:30:35 CEST 2017

The timestamp of the rpm files is correct compared to the master server.

Could it happen because create-filelist from quick-fedora-mirror records the modtime as the max of the mtime and the ctime, while rsync -a seems to only preserve the mtime on the destination ?

Could be I guess. Not sure.

@tibbs any ideas here?

As far as I can tell, the values in the file list are exactly what they should be. If you expect the value of that field to have any correspondence with any timestamp you can see with rsync, you will be disappointed. And it's not as if rsync (or anything else not running as root) can set both the file mtime and the inode ctime to an arbitrary value anyway.

It has never been intended for that value to be useful for anything other than detecting changes on the server, and you certainly should not expect to be able to do the kind of checks you are doing.

The files in question were probably linked elsewhere in the tree on the master servers. Certainly the recent linking of several older releases to archive has modified a load of inodes on the server.

Ah ok, I understand. It is effectively meaningless to compare a timestamp from the fullfiletimelist file with the ctime of mtime of a file on my mirror. This issue can be closed. Thanks for the explanation!

:diamond_shape_with_a_dot_inside:

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.