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.
I’ve just come across this again, where I’m really seeing space being used up. A user has cloned their event from last year, to make a new starting point for this year’s similar event. And along came a copy of all the attached files! And there’s no point in me asking the user to delete the files from the new event, since they won’t really get deleted.
Felt I should share this for anyone else with the same issue.
I wonder what will happen if I simply delete all the files under event/NNNN/contribution, since I know they aren’t needed?
There will be database entries referencing them, but since those are marked as deleted anyway, this won’t cause any problems.