Skip to end of metadata
Go to start of metadata

Delete File Communication uses the general communication pattern with an IdentifyPillarsForDelete and a Delete Primitive.
The xsd's for the different messages can be found here.

Communication Pattern

  • Client sends IdentifyPillarsForDeleteFileRequest message with FileID, and all pillars which have files for the bit repository collection reply with IdentifyPillarsForDeleteFileResponse messages
  • Client sends DeleteFileRequest messages with FileID to the relevant identified pillars and the pillars can reply with DeleteFileProgressResponse
  • Data will now be deleted on the specified pillars and DeleteFileFinalResponse messages sent (note that the SLA will probably specify a 'roll-back-period' during which the data will be in an 'under deletion state' and a roll/back can be done manually)

Note that delete can either be of

  • all copies of the file
  • or a copy on a specific pillar

The difference is made in the choice of which pillars to send the DeleteFileRequest

IdentifyPillarsForDeleteFile Primitive

The primitive consists of IdentifyPillarsForDeleteFileRequest and IdentifyPillarsForDeleteFileResponse.

DeleteFile Primitive

The primitive consists of DeleteFileRequest, DeleteFileProgressResponse and DeleteFileFinalResponse.

  • No labels