#32718: [3.2.1] Issue with assigning file to FileField
-------------------------------------+-------------------------------------
Reporter: Jakub Kleň | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: 2.2
(models, ORM) |
Severity: Release blocker | Resolution:
Keywords: 3.2.1 file model | Triage Stage: Accepted
filefield fieldfile |
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Jakub Kleň):
Replying to [comment:15 Jakub Kleň]:
> Replying to [comment:14 Florian Apolloner]:
> > Replying to [ticket:32718 Jakub Kleň]:
> > > Correct me if I'm wrong, but file-like objects always contain the
full path to the file in the `name` attribute (the built-in Django `File`
class even uses it to reopen the file if it was closed), and so it seems
to be a bug in Django itself.
> >
> > This is true, but according to my tests on earlier versions a full
(absolute) path did fail already because it would usually be outside the
MEDIA_ROOT. Can you provide some more details?
>
> I am setting the images as I described in the initial post, with
absolute paths which are outside of `MEDIA_ROOT`, and am not having any
issues with it. I'm currently actually using v3.2.1, because I had to
update. I initially updated to 3.2.0, but that caused some crashes because
of a bug in legacy cookie decoding, so I really had no other option than
to update to 3.2.1. So I temporarily monkey patched
`django.core.files.utils.validate_file_name` to just `return name`, and
everything works perfectly.
>
> Regarding the `FileField.save` method and the parameter it takes, to me
it kind of makes sense to only pass in the basename of the file. I'm not
completely sure if we should be passing in a path in the case of
`pre_save`. It doesn't make sense to me to derive the final path of the
file from that. The full path should be generated in a custom `upload_to`,
and that parameter should only be used to e.g. reuse the same extension of
the original file. But not to append that full path to `upload_to`. Note
I'm talking only about this special case with `pre_save`, where files set
to the model fields are handled. It would still be possible to manually
call `field.save('some/path/file.png`. Although I'm not sure why someone
would do that, because the path should be provided in `upload_to` I think.
But I know we also have to think about backwards compatibility, so I'm not
quite sure what is a viable solution here.
>
> Imagine the following scenario (assuming the FileField has
`upload_to='media'`):
> {{{
> model.file_field = File(open('/folder/file.png', 'rb'))
> model.save()
> }}}
> Should the file be written to `media/folder/file.png`? I don't think the
final path in `MEDIA_ROOT` should depend on the original path of the file.
> And we can't even provide `File(open(), name='file.png')` manually,
because it would break `File.open()` where the `name` is being used.
> If you want to provide a custom path during `save`, you can still do
that by manually calling `file_field.save(path`, but in this special case
of `pre_save`, where the `name` is the full path, I think it would make
sense to only use the basename.
>
> I'm not completely sure what Django does by default when `upload_to` is
a path (string), as I'm using a callable where the only thing I take from
the filename is the extension, which I reuse. So both ways will work for
me.
Sorry, I was mistaken. It wouldn't be possible to even do it manually
using `file_field.save(path`, because the check if made inside the
`FileField.save` method. But it still kind of makes sense to me for the
`FileField.save` method to only take the basename. But I'm not sure
everyone would agree, and it would be a backwards incompatible change.
--
Ticket URL: <https://code.djangoproject.com/ticket/32718#comment:17>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/064.59dc3c830ce0a2981120d1dcf1c3d14c%40djangoproject.com.
