What this is about
A file model has two parts: the record in the database (name, size, fileId and your own fields) and the content in the file storage. For audited file models, the storage also holds the old versions of every upload. See File versions.
When the record is deleted, CDMS deletes the content along with it, and that means all versions. A file model whose record is gone has no readable content left. This matters for personal data: a deletion is only a deletion once the bytes are gone too.
Record and content
-
1Client→CDMSsends
DELETE /fileasset/delete/f1… -
2CDMSchecks visibility and the delete role of the file model
-
3CDMS→File storagenotes that the content is to be removed: the current file and all retained versionsIt is noted during the delete flow as soon as CDMS reaches the record. It is removed only after the database commit.
-
4HookDELETE hooks run
-
5CDMS→Databaseremoves the record and commits
-
6CDMS→File storageremoves the content including versionsResult: 200 without body.
GET /fileasset/f1…/filereturns 404 afterwards.
In the file storage it looks like this, for an audited file model with three uploads:
| File in storage | before | after |
|---|---|---|
<fileId> (current content) | “version three” | deleted |
<fileId> + version identifier | “version two” | deleted |
<fileId> + version identifier | “version one” | deleted |
Which files go along
A file can hang on another object, such as the logo of a company or the attachments of a dossier. Whether it goes along when that object is deleted is, as always, decided by the DELETE flag. See Dependent objects (cascades).
| Relation | Example | Flag DELETE | File |
|---|---|---|---|
| 1:1 | Company.logo | yes | record and content deleted |
| 1:n | Dossier.attachments | yes | every attachment deleted, with content |
| n:1 | Dossier.template, one template for many dossiers | no | stays with its content, even if no dossier points to it anymore |
| n:m through a join model | Dossier.assets → Dossier2Asset.asset | yes on the join, no on the file | the connections go, the file stays |
So a shared file stays, even when the last object pointing to it is deleted. CDMS does not clean it up by itself. If you no longer need it, delete it directly.
Removed through PUT or PATCH
If a dependent attachment drops out of its list through PUT or PATCH, it is deleted, likewise with its content and versions. See Deleting by changing.
Replacing a file is something else: a new upload to the same record deletes nothing; for audited models the old content becomes a version. See Replacing and renaming.
What remains of a deleted file
- the history of the record: name, size, who uploaded and deleted it and when
- the record
- the current content
- all versions
- every way to download an old content
So the history shows that the file existed and what it was called, but no longer what was in it. See What remains after a delete.
Pitfalls
What comes next
- The steps of a DELETE: How a DELETE runs
- Files and transaction: Files and transaction
- Old states: File versions