Hi Antonio Pleased to hear the feedback is useful.
On 22/01/2025 17:20, Antonio Diaz Diaz wrote: > It seems some incompatibility between touch and --mtime for fringe dates. > All the other tests pass, so it should be safe to use the compiled tarlz. > > I think I'm going to limit the --mtime test to dates since the epoch up to > the year 2242 to avoid these incompatibilities with touch. Sounds like a sensible course of action. One other piece of feedback, which is also probably some sort of bug, though probably difficult to diagnose. I tried creating a moderately large tarlz archive (approximately 1.5GB), using compression option '-9'. Other options were as per tarlz defaults. Since this archive was simply being used to backup a whole bunch of random files, it also included already compressed files, in particular an AppImage.tgz file. Anyway, here is where the possible interest lies: using compression level '-9' with everything else as per defaults appears to have generated a faulty archive. In particular, listing the entire contents of the tarlz archive via '-tf' caused it to abort/stop with "data error" with the AppImage.tgz file as the last entry, so I presume that was what it was failing on. Creating the exact same archive again, but without specifying any compression level so it uses the default value, results in an archive that looks to work/behave perfectly, with no issue with the aforementioned file. (It is also very noticeably faster when listing, etc., though one would expect that). So: 1. It is "normal" that using maximum compression level '-9' can cause some failures/problems with created archives? I would presume not, especially as there was no error output or anything to indicate at creation time that there was any issue with the newly created archive. 2. If not, I can try to get you some more diagnostic information, I presume I can simply use some verbosity switches to get tarlz to be more informative about the underlying issue. 3. I presume the fact that the archive lists all files without apparent issue with default compression settings means its integrity can be trusted. I suppose I can run some spot checks. I am just checking because my intention was to switch over to using tarlz as my default backup format precisely because of the extra integrity/recovery/safety it provides versus a stock tar.xz archive. Looking at the difference in file size, it seems there is little value deviating from the stock/default compression level anyway, as the additional compression achieved was pretty minimal. So the real question is, does using '-9' occasionally trigger bad side-effects that otherwise never occur with default compression setting. Thanks Aree.
