Re: Tarlz 0.26 'make check' test failure on Debian 12

[Aren Tyr]

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.