Page History

...

At the OCFL layer a tombstone is indicated as a change in the hidden Fedora files. These sidecar files Fedora uses to track various Fedora Header File for the deleted resource. Fedora uses these sidecar files to track information the application needs for each resource. Nothing is removed when the object is "deleted" instead the sidecar file fcr-root.json file is updated to change the value of the "deleted" key from "false" to "true" (as well as the "lastModifiedDate" value)

...

It is understandable that in some situations you might want to complete completely remove a resource and rebuild it. In this situation you need to "purge" the object from your repository. To do this you make a "delete" request to the tombstone itself.

You can find the tombstone's URI by checking the headers returned on the deleted resource.

...

For example looking at the OCFL root directory of a respository repository with only the deleted resource "test-resource" before the purge.:

.
└── ocfl-root/
    ├── 0004-hashed-n-tuple-storage-layout.md
    ├── 0=ocfl_1.1
    ├── 141 <- the repository root resource
    ├── 5ce <- the deleted resource "test-resource"
    ├── extensions
    ├── ocfl_1.1.md
    ├── ocfl_extensions_1.0.md
    └── ocfl_layout.json

After purging the resource "test-resource", the OCFL root looks like this.:

.
└── ocfl-root/
    ├── 0004-hashed-n-tuple-storage-layout.md
    ├── 0=ocfl_1.1
    ├── 141 <- the repository root resource
    ├── extensions
    ├── ocfl_1.1.md
    ├── ocfl_extensions_1.0.md
    └── ocfl_layout.json

Because no other resource resources in the repository shared the same starting to the hash of the namewere stored within the "5ce" directory in this example, the entire directory structure was removed. See Fedora OCFL Object Structure#StorageHierarchyLayout for details of how these subdirectories are named.