This patch is two-fold; first it ensure that Django does close everything in
request.FILES at the end of the request and secondly the storage system should
no longer close any files during save, it's up to the caller to handle that --
or let Django close the files at the end of the request.
Added condition to prevent checking the existence of a file name of a
file like object when the name attribute is None. This is necessary
because a SpooledTemporaryFile won't exist on the file system or have a
name until it has reached its max_size. Also added tests.
Due to a mixup between text and bytes, iteration over
a File instance was broken under Python 3.
Thanks to trac user pdewacht for the report and patch.
There wasn't any file locking under Windows unless PyWin32 was
installed. This removes that (undocumented) dependency by using ctypes
instead.
Thanks to Anatoly Techtonik for writing the ctypes port upon which this
is based.
Previously when collecting static files, the directories would receive permissions
from the global umask. Now the default permission comes from FILE_UPLOAD_DIRECTORY_PERMISSIONS
and there's an option to specify the permissions by subclassing any of the
static files storage classes and setting the directory_permissions_mode parameter.
Previously, when collecting static files, the files would receive permission
from FILE_UPLOAD_PERMISSIONS. Now, there's an option to give different
permission from uploaded files permission by subclassing any of the static
files storage classes and setting the file_permissions_mode parameter.
Thanks dblack at atlassian.com for the suggestion.
- Noted that this does not allow for reading and writing the same open
file in different processes under Windows.
- Noted that the keyword arguments to NamedTemporaryFile no longer
match the Python version.
- TemporaryFile now minimally mocks the API of the Python standard
library class tempfile.NamedTemporaryFile to avoid AttributeError
exceptions.
- The symbol django.core.files.NamedTemporaryFile is actually assigned
as a different class on different operating systems.
- The bug only occurred if Django is running on Windows, hence why it
was hard to diagnose.
SuspiciousOperations have been differentiated into subclasses, and
are now logged to a 'django.security.*' logger. SuspiciousOperations
that reach django.core.handlers.base.BaseHandler will now return a 400
instead of a 500.
Thanks to tiwoc for the report, and Carl Meyer and Donald Stufft
for review.
Loic Bistuer
Florian Apolloner
Claude Paroz
Alex Gaynor
Andrew Godwin
Baptiste Mispelon
Hans Lawrenz
Tim Graham
smallcode
Rodolfo Carvalho
Dmitro
Kevin Christopher Henry
Berker Peksag
José Moreira
Loic Bistuer
Vajrasky Kok
xuxiang
Milton Mazzarri
coagulant
Alasdair Nicol
Gregor MacGregor
John Hensley
homm
Christopher Adams
Aymeric Augustin
Mel Collins
Benjamin Kagia
Russell Keith-Magee
Ramiro Morales
Preston Holmes
Daniel Lindsley
Marcin Biernat
Anton Baklanov