Child pages
  • Delete all copies of a data object including checksums copies

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3


The user story is that a data object is deleted as result of a discard policy.


Note that there need to be decisions on whether the audit trail is still available.

From the user point of view, the functionality is 'Delete File from Bit Repository'.

This is all the user needs to know. The user will tell the application or DeleteFileClient which file should be deleted from the bit repository. The DeleteFileClient will handle the specifics of what to send and whereto and finally respond to the user. If all goes well, the steps involved are the following:

The DeleteFileClient needs to find out which pillars have a copy of the file, that is to be deleted (including checksum pillars). This is done in the following steps

  • the Client sends an IdentifyPillarsForDeleteFileRequest to identify the pillars where the file should be deleted from
  • three pillars send an IdentifyPillarsForDeleteFileReply with their pillarID and replyTo address. One of the replies is from a checksum pillar and also tells the checksum type.
  • the client checks that these were the expected pillars according to SLA

Next the client requests delete file from all identified pillars.

  • the client sends three DeleteFileRequest messages to the replyTo addresses received from the three pillars. The message to the checksum pillar can include the checksum type of the pillar for checks. All the messages include checksum of the file (and checksum type) as a checksum check is required to perform the Delete File operation on the pillar.
  • the three pillars perform the checksum checks and send a DeleteFileProgressResponse message with response codes telling that the DeleteFileRequest has been received and the status of the operation on the pillar.
  • the Client can now tell the user that the file is being deleted from the bit repository.
  • the pillars move the file from the bit repository to a temporary 'under deletion storage area'.
  • the pillars send DeleteFileFinalResponse messages with response codes.

The file is now kept in the 'under deletion storage area' on the pillar for a specified period of time. This 'undo period' is specified in the Service Level Agreement. If a deletion turns out to be a mistake, the pillar owner is contacted, and the file can be recovered.

Note that the 'undo period' explained in this user story, is not part of the protocol, but it is expected to be part of a Service Level Agreement.

Children Display