Some Packages Install Files With Bespoke Creation Times

[John R. Graham]

I happened to notice that the app-misc/pax-utils build process messes with the creation times of its compiled executables. pax-utils sets the creation time of some of its compiled executables but not all to the creation time of the C source code that contains main().

Although this messes up something that I'm trying to do, it's obviously intentional—and not a bug. What's the rationale? For source code that's installed as-is, I can understand, but for generated executables? Could it be that the program's timestamp is used as sort of an implicit version number for the utility?

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.

[Genone]

Do you mean ctime? That isn't the "creation" timestamp, but the time when file metadata was modified (while mtime refers to when the files actual data was changed). Otherwise you have to be more specific what you mean.

[John R. Graham]

Ah. Thank you for the precision. Upon further study...just forget I asked. The files I was looking at in /usr/bin weren't generated executables but scripts that were being passed through the build process unchanged.

In the process of realizing that I was wrong, I have learned that Portage handles the merge process in an extremely careful and conservative fashion. For instance, even generated executables, which are demonstrably new files with new Inodes in the working directory, do not become new files with new Inodes in the live filesystem if they don't need to be. The times associated with the live filesystem files also seem to be carefully curated.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.