I recently had to repair an archive damaged when a cat disconnected the drive the archive was contained on during a capture.

I repaired the drive, but it failed when I verified it, so I ran repair again, after which it verified OK.

I now have 2 different layers within the archive which show as <layer#><Date> Zero KB Repaired

(strangely to me the dates of these layers are from 2017 & early 2020 -- I would have expected them to be near the date of the interrupted capture?)

?What is the status of those 2 layers?
?Why are they displayed?
?If they now are empty, shouldn't a Merge have removed them?
?What happened to the data contained in them? (I would have expected any unrecoverable data to be at the end of the archive where it was being added to when interrupted?)

Following a repair, QRecall makes the following guarantees:

All items (unless you set some of the special repair options) in a layer have been verified to be undamaged and can be recalled.

Layers that are not marked as "repaired" are complete and aren't missing any items

The inverse implication is that layered marked as "repaired" might be missing items?there's no way for QRecall to tell?but the items that are there are OK.

Now to cover some of the minutia of the repair process...

A "Zero KB" just mean that QRecall couldn't (easily) reconstruct the size of that layer. Like the Finder, QRecall would have to scan every folder and item in a layer to fully reconstruct its size, and repair won't do this more than one folder level deep. Maybe that's a bug. Maybe it's just "hey, the layer was damaged; there's stuff about it we don't know anymore, sorry." So those layers aren't empty and you should find items in them if you browse them on their own (move both layer shades so only that layer is visible).

About the dates and layer order. If layer records are missing, the repair can reconstruct most of the information about that layer from the individual folder and file records. Every folder record has a "layer ID", so by scanning the folder records it's possible to put them back into their original position in the layers. But if the layer records were damaged or missing, some information (like that date that layer was captured/merged), has to be inferred from the dates of the individual folders. It should to be close, but it won't be exact.

Finally, if you merge a repaired layer with a subsequent layer and that subsequent layer completely captured all the same items, that repaired layer will disappear. If not, then the merged layer will still have remnants of the repaired layer and will also be marked as "repaired".

Let me know if that helps, or confuses the matter even more.

James, let me chew on your reply (have to feed the cats now) but I do have a suggestion from the Human Interface Design point: To many, seeing a "Zero KB" value is misleading; what it really means here is "We don't know" but Zero may be interpreted as: 0, nothing, OMG all of it is gone!

How about using something else like "Unknown" or "?" instead when a value can't be computed?

Looking at the code, the layer size should read "Unknown" for a repaired layer. Not sure why you're seeing Zero KB, but I'll dig a little deeper into it. Probably a bug.