id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
26562	Introduce Storage and FileSystemStorage alternate save behaviour	Matt C	nobody	"I have read through many discussions about justifying why uploaded files should not be deleted or overwritten, but I don't agree with them at all (I can get into that if needed) and I think the current implementation of `django.core.files.storage.Storage.get_available_name()` and `django.core.files.storage.FileSystemStorage._save()` are quite undesirable.

The behaviour I am referring to is the fact that the `Storage.get_available_name()` method is so crucial to the whole storage and `FileField` game and yet its implementation is susceptible to race conditions and that it is the root cause of a dev not being granted total control of the '''final''' file/storage path when saving a file using the storage API.

Flow on from that, the fact that the `FileSystemStorage._save()` method infinitely loops until a file path collision does not occur (to open a file) and then uses low-level locking mechanisms to try and retain ownership of the file for writing.

If the core devs are keen on retaining this behaviour, so be it.
However, can we please build upon Django's reputation of configurability and allow for an alternative (and non-default, to appease backwards compatibility) behaviour where `Storage.get_available_name()` effectively does nothing (except maybe length truncation) and `FileSystemStorage._save()` does not have the infinite loop and does not have the low-level file lock.

My proposals for configurability are:
* Global setting in the settings file
* Static attribute of the `Storage` class, which can be overridden"	New feature	new	File uploads/storage	dev	Normal		file FileField storage overwrite filepath	piethon@…	Accepted	0	0	0	0	0	0