Opened 15 years ago

Closed 15 years ago

Last modified 13 years ago

#10788 closed (wontfix)

Actual name of uploaded file available later than it was in 1.0

Reported by: Karen Tracey Owned by: Jacob
Component: File uploads/storage Version: dev
Severity: Keywords:
Cc: Armin Ronacher 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

Originally reported here: http://groups.google.com/group/django-developers/browse_thread/thread/ce20f196f5e85296#

Prior to r9766 an uploaded file was saved during model form save (even when commit=False) by a field save_form_data override. Thus the actual name (including upload directory and any appended underscores) used for a FileField was available to pre-save signal handlers and any code that ran after a ModelForm.save(commit=False). r9766 delayed the actual file save to much later in the model save process (a field pre_save routine), so some code that used to be able to use the actual file name no longer can.

(There are other side-effects of r9766 still open: #10404, #10300, #10249 but these are all slightly different issues. In the end we might choose to decide to deal with them all en masse somehow, but just to make sure this particular wrinkle isn't forgotten I figured it should have its own ticket.)

Change History (12)

comment:1 by Jacob, 15 years ago

Triage Stage: UnreviewedAccepted

comment:2 by dc, 15 years ago

Is this is really in scope of 1.1? Maybe better move this ticket to 1.2 as this is not a bugfix.

comment:3 by Karen Tracey, 15 years ago

How could this be out of scope for 1.1? We've changed things such that application level code that used to be able to access the actual file name at a certain point in the processing path no longer can. That's a regression. We either need to restore the old behavior or at a minimum document the change.

comment:4 by dc, 15 years ago

You are right - this is in scope of 1.1. Sorry for the false alert.

comment:5 by Armin Ronacher, 15 years ago

Owner: changed from nobody to Armin Ronacher

comment:6 by Armin Ronacher, 15 years ago

Cc: Armin Ronacher added
Owner: changed from Armin Ronacher to Jacob
Triage Stage: AcceptedDesign decision needed

The core no longer depends on that and I stronly suggest designing custom upload handlers in a way that they don't depend on the final filename of the file on the filesystem. This however is slighty backwards incomaptible as it seems so it requires a decision by a main developer.

in reply to:  6 ; comment:7 by anonymous, 15 years ago

Replying to mitsuhiko:

The core no longer depends on that and I stronly suggest designing custom upload handlers in a way that they don't depend on the final filename of the file on the filesystem. This however is slighty backwards incomaptible as it seems so it requires a decision by a main developer.

It's totally incompatible with every code I could see that needs to rename (uploaded) files. To rename the file, you have know its name first, but in the current status, this is not possible anymore (especially in pre_save() signals).

in reply to:  7 ; comment:8 by Armin Ronacher, 15 years ago

Replying to anonymous:

Replying to mitsuhiko:

The core no longer depends on that and I stronly suggest designing custom upload handlers in a way that they don't depend on the final filename of the file on the filesystem. This however is slighty backwards incomaptible as it seems so it requires a decision by a main developer.

It's totally incompatible with every code I could see that needs to rename (uploaded) files. To rename the file, you have know its name first, but in the current status, this is not possible anymore (especially in pre_save() signals).

Why would you need to rename a file? Can't see how this is useful. Just set the filename before the file is saved by the model then you don't have to rename the file, it would be stored with the correct name.

in reply to:  8 comment:9 by Lior Gradstein, 15 years ago

Replying to mitsuhiko:

Replying to anonymous:

Replying to mitsuhiko:

The core no longer depends on that and I stronly suggest designing custom upload handlers in a way that they don't depend on the final filename of the file on the filesystem. This however is slighty backwards incomaptible as it seems so it requires a decision by a main developer.

It's totally incompatible with every code I could see that needs to rename (uploaded) files. To rename the file, you have know its name first, but in the current status, this is not possible anymore (especially in pre_save() signals).

Why would you need to rename a file? Can't see how this is useful. Just set the filename before the file is saved by the model then you don't have to rename the file, it would be stored with the correct name.

Well, not necessarily renaming a file, in fact it's just accessing it. We don't have the path to access it. Just look at the example in the original django dev thread (http://groups.google.com/group/django-developers/browse_thread/thread/ce20f196f5e85296 ).

As a real use-case (simple) example which is often used, for an uploaded image (put in an ImageField), generate a thumbnail for it, using the pre_save() signal.

comment:10 by Jacob, 15 years ago

Resolution: wontfix
Status: newclosed

Given Armin's notes here, and Marty's concurrence on django-developers (http://groups.google.com/group/django-developers/browse_thread/thread/560b3d7cad9bd491), I'm going to mark this wontifx and note in the 1.1 release notes that the final file name isn't available until the file has actually been saved to disk. It's of dubious use anyway to allow someone to try to "predict" the final file name; better to use the storage APIs always to access the given object.

in reply to:  10 comment:11 by anonymous, 15 years ago

Replying to jacob:

Given Armin's notes here, and Marty's concurrence on django-developers (http://groups.google.com/group/django-developers/browse_thread/thread/560b3d7cad9bd491), I'm going to mark this wontifx and note in the 1.1 release notes that the final file name isn't available until the file has actually been saved to disk. It's of dubious use anyway to allow someone to try to "predict" the final file name; better to use the storage APIs always to access the given object.

I find it really disturbing for someone that comes for the first time and *thinks* that's it's possible (especially when it was possible in 1.0, and you'll get a lot of references on the web on 'tips' and similar usage) to access the filenames in a pre_save signal.

The problem is that *if* you don't know that it's impossible now, you'll try to access instance.attribute.path (which contained the correct path to the file in Django 1.0) and get a result, but a wrong one! Isn't it possible to prevent access to the attribute or at least set it to something that will not be interpreted as "strange"?

comment:12 by Jacob, 13 years ago

milestone: 1.1

Milestone 1.1 deleted

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