Delete file can be used as part of a Replace File operation. In connection with integrity corrective action the possibility of deleting an object on just one pillar may be needed. An actual delete of an object will be a delete of all copies in the bit repository.
The Delete operation will given an ID, delete the bits (full copy or checksum) identified from the repository or from the specified pillar. The delete protocol functionality requires checksum data to assure the correct file is deleted, but it does not provide a roll-back functionality. It is assumed that this is part of the service level agreement and requires manual intervention.
What are the user stories of the delete functionality?
- Delete all copies of a data object including checksums copies — The user story is that a data object is deleted as result of a discard policy.
- Delete file on one checksums copy pillar as part of internal integrity processesing — Analyze in which cases this is wanted - e.g. if bit repository collection is skipping a checksum copy
- Delete file on one full copy pillar as part of internal integrity processesing — Analyze in which cases this is wanted - e.g. if bit repository collection is skipping a copy
Delete File Communication uses the general communication pattern with an IdentifyPillarsForDelete and a Delete Primitive.
- IdentifyPillarsForDeleteFile Primitive — The primitive consists of IdentifyPillarsForDeleteFileRequest and IdentifyPillarsForDeleteFileResponse.
- DeleteFile Primitive — The primitive consists of DeleteFileRequest, DeleteFileProgressResponse and DeleteFileFinalResponse.
Summary: A manual roll-back possibility can be written into a Service Level Agreement.
The undelete discussion has ended with an agreement that a manual roll-back possibility can be written into the SLA.
- Undelete — Considerations to undelete; part of the two-phase commit analysis BITMAG-68@JIRA