Superseded copy numbers get mixed up in retrieves. We should retrieve active copies and superseded ones as a backup.

Summary

The selected copy number is currently referenced by copy number only during retrieves and this is not sufficient as we can have several tape files on different tapes going by the same copynb.

[ ] A short term solution is to limit the tape files stored in a retrieve request to the non superseded ones. [ ] The long term solution is to have retrieves first exhaust the non-superseded tape files before resorting to the superseded ones.

Steps to reproduce

When retrieving a an archive file that got written several times to tape (retries, repack), is the retrieve will be attempted on the fseq/blockid for the tape file

What is the current bug behavior?

Repack the file, then retrieve. The actual outcome depends on history and other present retrieves (impacting the seletion of the tape file).

What is the expected correct behavior?

The minimum correct behavior is to ensure the tape file retrieved is the right one.

Relevant logs and/or screenshots

Possible fixes

Minimal fix: ensure we have one tapefile per copynb by not putting the

Complete fix: ensure we exhaust the active tape files before falling back to the seperseded ones.