[Dar-support] Need help determining sliced archive corruption

[mannino <ma...@of...>]

I have two different systems that back up data using incremental 
archives. Those incremental archives (there's about 200 of them) are 
fine according to dar -t. However, base (full) archives produced on both 
systems at different times are reported as corrupted.

Adding -va to -t provides little insight into what's going on:

   # dar version 2.7.17

   Auto detecting min-digits to be 2
   Opening archive aa ...
   Opening the archive using the multi-slice abstraction layer...
   Reading the archive trailer...
   Final memory cleanup...
   FATAL error, aborting operation: Unexpected value while reading 
archive version

   # dar version 2.7.15

   Opening archive aa ...
   Opening the archive using the multi-slice abstraction layer...
   Reading the archive trailer...
   Final memory cleanup...
   FATAL error, aborting operation: Unexpected value while reading 
archive version

When creating archives, I don't use any fancy options, just -zgzip, 
-A/-@ and -s/-E. I do have isolated catalogues in addition to the 
archives themselves but adding -A to -t or -l doesn't change anything.

Archives are stored on a separate machine; it's possible that a 
corruption indeed took place when those archives were being transferred 
from hosts but those hosts are different enough to make it unlikely that 
that would happen to both at once.

I tried checking with strace to see what files dar -t opens. For both 
archives, it starts with the last one in the directory, then opens some 
seemingly random one in the 2/3rd of the set (I have ~30 and ~100 slices 
so it opens the ~30th/~70th respectively), then after a bunch of seeks 
it fails.

I tried -t -0. It resulted in an entry like so for 4 files:

   can't read data CRC: No escape mark found for that file

...followed by this output:

   --------------------------------------------
   1619434 item(s) treated
   4 item(s) with error
   0 item(s) ignored (excluded by filters)
   --------------------------------------------
   Total number of items considered: 1619438
   --------------------------------------------
   Final memory cleanup...
   Some files are corrupted in the archive and it will not be possible 
to restore them
   +++ exited with 5 +++

No other errors were logged. None were logged for the first and last slices.

Does it indicate that the archive is fine sans for 4 files' data? Then 
what's with that "Unexpected value" error in direct mode?

I also tried some combinations of -l and it really puzzled me.

-l alone; -l -q: fail just like -t.

-l -0: after some output, fails with Error while listing archive 
contents: can't read data CRC: No escape mark found for that file

-l -q -0: fails with (???):

   Sorry, file size is unknown at this step of the program.
   The last file of the set is not present in file:///, please provide it.

Finally, I tried -al to no avail:

   LAX MODE: Failed to read the archive format version.
   LAX MODE: Please provide the format MAJOR number: 11
   LAX MODE: Please provide the format MINOR number: 3
   LAX MODE: Using archive format "11.3"? [return = YES | Esc = NO]
   Continuing...
   LAX MODE: Unknown compression algorithm used, assuming data 
corruption occurred. Please help me, answering with one of the following 
words "none", "gzip", [...] at the next prompt:gzip
   Unknown crypto algorithm used in archive, ignoring that field and 
simply assuming the archive has been encrypted, if not done you will 
need to specify the crypto algorithm to use in order to read this archive
   Error met while reading archive of reference slicing layout, ignoring 
this field and continuing
   Aborting due to exception: Badly formed "infinint" or not supported 
format

One plausible cause is that I have mixed up the slices (lost or 
duplicated some intermediate slices). It seems dar header can't help me 
here (it doesn't store slice index) but other evidence suggests it's not 
the case (`file *.dar` outputs the same label, slices' file sizes and 
times look sane, etc.).

Is -t -0 guaranteed to catch the situation when slices are mixed up?

For good measure, I tried -t'esting with dar 2.7.x and 2.8.x but results 
were the same.

I really don't know what to make of this or what else to try.

Any help on finding the cause for corruption is much appreciated.