[Redirecting to bug-tar.] Collin Funk wrote in <https://lists.gnu.org/archive/html/bug-gnulib/2024-03/msg00189.html>:
> $ tar -xf eclipse-inst-jre-linux64.tar.gz > gtar: Ignoring unknown extended header keyword 'LIBARCHIVE.creationtime' > gtar: Ignoring unknown extended header keyword 'LIBARCHIVE.creationtime' > # and many more times... IMO, there is no point in having the 'creationtime' of a file in the tar file of a package. Rationale: * Tar can be used for making backups or for transporting directory trees between machine. While, in the former case, it can be debated whether sysadmins want the file creation times restored when they restore some data from backup, for the second case it's clear: There is no need to fake a file creation time on the disk of the user who runs "tar -xf". The European GDPR asks for minimizing the collection of data that is necessary for the job. mtime is necessary for transporting a package to a different machine. Even atime is not. But ctime and creationtime are not either, even less. * On Linux, it's not even possible to set the birthtime of a file, if that is meant to mean the ctime (change time). Bruno