irmtrash -M can lead to unexpected data loss

[michael-conway]

• master
• 4-2-stable

---

Bug Report

iRODS 4.2.4. Mix of reg'd and vault data sets. irmtrash -M causes potential data loss. We saw this in both the reg'd files and in the vault itself.

On the registered side It appears that if a reg'd file goes in the trash, removing the trash will delete the underlying file unless it is removed with rm -U. It is highly desireable that either the rm operation or the rmtrash operation should either warn or prevent this (and this appears to be discernable by looking at the physical path?) The rm operation should not, since it operates on a logical file level, force the operator to have foreknowledge of the underlying storage architecture.

The second case, where it appears that irmtrash -M appears to have deleted data sets in the actual iRODS vault is something that needs to be investigated. We have grabbed the rodslog for the time period and will start trying to reconstruct what happened, but some verification of the logical/physical path may help here in case there truly is a bug that can lead to data loss.

iRODS Version, OS and Version

4.2.4

What did you try to do?

irmtrash -M

Mix of vault data and registered data

Expected behavior

Trash operation should not delete physical files that are in the catalog that are not in trash

Observed behavior (including steps to reproduce, if applicable)

See above will begin assessing logs for add'l data

[trel]

Case 1) Non-vault, registered files - which had been put into the trash

We can definitely look at providing more bumpers/expectation around removing/deleting non-vault registered files. For this deletion to occur, it means that the iRODS service account had write permission to the registered non-vault files. Was this write permission intentional in your case?

It is known/expected for iRODS to unlink registered non-vault files if it has permission to do so. Files in iRODS are considered 'under management'. We may need more warnings/redletters that explain this.

If the iRODS service account does not have write permission on those files, it cannot delete them, but will still remove their entries from the catalog if irm'd.

Case 2) Files in an iRODS Vault - which had been put into the trash

This is... expected behavior? Can you explain a bit more about what happened that was unexpected in this case?

[trel]

The iRODS development team has made the decision that removing physical files (in the trash) that are not in an iRODS Vault is dangerous and unexpected.

This change removes that behavior - files in the trash, not in an iRODS Vault, will now only be unregistered if asked to be trimmed or removed. This ships in 4.2.8.