File dates from ROOL source tarballs

I just looked at the file dates/times of the HardDisc4 sources that I extracted from the ROOL DiscDev source code archive that I got recently. The dates/times all refer to the time that I extracted them. I found this disappointing; I wanted the last modification dates.

I went back to the archive and saw that the tar file was still there. On looking within it at the mbedTLS sources, I saw file dates 9 days earlier, except for h.roconfigawk, which has a 2023 date. Presumably this means that the dates refer to when the source code was last got from the mbedTLS site by the ROOL autobuilder, and the exception is a file that is “our own”.

Metadata that I think of as being important, are being lost along the way; on being got from elsewhere, and again on extraction.

Are these losses inevitable?

Do others feel these losses to be undesirable, or to be inconsequential?

Not really related, but all of the recent (this decade) version change information and history exists within git. It’s not a part of any source tarball, so the old changes are the Blacklog text files while the newer changes are… faffing around in the browser

I wonder if there’s some special option to export a .history file or somesuch for each component?

I may have answered one part of one of my questions. It occurred to me that I was looking at the tar file through SparkFS, so extracting the tar file via SparkFS should preserve the file dates and times in that stage. It appears to, but there’s a huge job of comparing the two extracted trees to do before I’m completely satisfied.

Hmm. SparkFS seems to get stuff wrong when extracting from a tar file when filenames reach about 122 characters, despite the setting of SparkFSTruncate 255 in its !Run file. The first mismatch I checked was a directory name that was 1 character short, and was a file instead of a directory. There are also 39 files less than when extracted by UntarBZ2.

This is version 1.55 (26-Jun-23).

The good news is that I can compare a whole tree of files (12610 in this case) in a few minutes.

I agree file datestamps are important meta data that should not be lost. Attaching a file to an e-mail or downloading a file loses the datestamp unless they are in a zip archive.

I think the only reasonable conclusion is that I have discovered two bugs: one in UnTarBZ2, and one in SparkFS.

UnTarBZ2 comes with sources, so I’ve got a version that preserves file dates/times. Presumably if I try some more tomorrow, I’ll be able to preserve the dates/times of directories too.

As I mentioned in another thread, OS_File 9 doesn’t seem to work for me.

I’ve had a search around, but I can’t see untar in gitlab, where I expected I’d be able to find it. Have I missed something, or am I looking in the wrong place? Presumably it has to be under source control somewhere. I’d like to submit my changes back – I’ve now got a version of untar that preserves all the file and folder date/time stamps.