What are some ways folks are deleting FileField files… and can we document this?

I’m curious to know what other people are doing to delete FileField files after the model instance is deleted or updated.

I was looking through the docs today to find the rationale for removing the old delete behaviour where deleting an instance would delete all FileField files along with it. I found out elsewhere that it was due to the irreversibility, which makes sense.

A small section in topics might be nice to explain that and some common ways to do it along with any caveats.

Things that come to mind:

  • Override delete() & save() (or use a signal or other means) to manually delete the file
  • Use django-cleanup
  • Setup a regular scheduled task to remove detached files
  • Move files to a trash can which is then emptied periodically. If you’re using S3 apparently you can set this pattern up with versioning.
  • Do nothing
1 Like

I’m in the “Do nothing” camp. For the project I have allowing users to upload files, those files “have a life” that exists beyond their usage in the project.

Aside from the irreversibility, you also have the possibility that a file may be referenced by other instances of the model in the same project, or by other projects.

You may also have a reference to a file that you cannot delete.

A file is a resource that may be external to Django and not necessarily under its control. There would be no way for Django to know what’s appropriate to be deleted and what isn’t. Personally, I’m extremely happy with the existing behavior.

1 Like

My vote goes to:

In general, unless there is a specific reason to, user data would fall under GDPR/other data protection schemes and should not be retained if they are deleted. One exception would be that you have a CMS and want to allow users to re-use uploaded files later or something like that.

1 Like