Opened 17 years ago

Closed 16 years ago

Last modified 13 years ago

#5966 closed (wontfix)

FileField doesn't clean up directory after deletion

Reported by: Michiel_1981 Owned by: nobody
Component: Core (Other) Version: dev
Severity: Keywords: fs-rf-docs
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

If a FileField file is being deleted it doesn't clean up a empty directory that might occur after deletion.
This is only a issue if you use a dynamic path based on date.

If this is the case then you could create a lot of empty directories and/or nested empty directories.
Example code:

class MetaFile(models.Model):
    file = models.FileField(_("File"), max_length=255,
                            upload_to='meta/%y/%m')

Change History (10)

comment:1 by Marty Alchin, 17 years ago

Keywords: fs-rf added

comment:2 by Marty Alchin, 17 years ago

Keywords: fs-rf-docs added; fs-rf removed

comment:3 by MichaelBishop, 17 years ago

Triage Stage: UnreviewedDesign decision needed

Why should an empty folder be delete after a file is deleted? I think that should be an individual design decision. However, a Django design decision is required.

comment:4 by Marty Alchin, 17 years ago

For what it's worth, when I added fs-rf-docs to this, it meant that my work on #5361 will make this behavior possible, but it won't be inclued by default. Instead, its documentation will show what hooks are available to make this happen. I'd also rather not see this behavior, but at least #5361 will make it possible for those who would like it. Just in case that helps with the design decision.

comment:5 by Michiel_1981, 17 years ago

for what it's worth, I override the FileField and add a dispather call to it for clean up if needed.
This ticket can be closed as you could override the delete method on the model or the above method.

I'll post on djangosnippets.org how this could be done if anybody is interested

comment:6 by Marty Alchin, 16 years ago

milestone: 1.0 beta

comment:7 by Michael Radziej, 16 years ago

milestone: 1.0 betapost-1.0

Not considered a bug => not 1.0 beta.

comment:8 by Marty Alchin, 16 years ago

milestone: post-1.01.0 beta

Bugs aren't the only things planned for 1.0 beta. This is being addressed as part of #5361, which is planned to make it into 1.0 beta. Even though it won't be fixed directly, the behavior requested in this ticket will be quite possible once that goes in. Per Jacob, all such related tickets should be placed in the 1.0 beta milestone.

comment:9 by Jacob, 16 years ago

Resolution: wontfix
Status: newclosed

File storage is in as of [8244], so I'm marking this as wontfix -- as Marty says, it's very easy to write a custom file storage backend that works exactly how you like it.

comment:10 by Jacob, 13 years ago

milestone: 1.0 beta

Milestone 1.0 beta deleted

Note: See TracTickets for help on using tickets.
Back to Top