During testing, I found that adding a file attachment to an event, and then deleting it again, doesn’t (in my case at least) remove the actual file from the archive area of the filesystem. Is this expected, or a bug (I’m on 3.2.9), or some issue with my set up?
I then even deleted the event itself, and the attachment file remained.
This make me think our very old Indico service (dates from 2010) will have a whole load of orphaned baggage I could remove, if only I could identify it!
Thoughts?
Yes, this is expected since attachments like most other things are soft-deleted.
You could query the DB for attachments with is_deleted being True, and then delete those from storage + DB. Probably the storage gain is not significant enough to make it worth the effort though.
You could also consider to move to a S3-compatible storage at some point - our import script for that only copies attachments (including soft-deleted ones though) that are still referenced in the database. So anything that’s truly orphaned would not be copied.
OK thanks. As long as this is expected behaviour, I’ll leave this on the back burner for now.