With my Django Fellow hat on, I would say:
- Any custom “path splitting” logic added to this class could potentially introduce a future DoS risk in
Storage.get_available_name
, so I would advise against addingsplit_stem_suffix
to the base Storage class. - The base
Storage
class should ideally be filesystem-ignorant, and any further customizations should be evaluated forFilesystemStorage
. (I understand this isn’t strictly the case at present in the Django code base, but we definitely shouldn’t make it worse.) - Previous discussions have highlighted the need for redesigning the Storage API to enhance its extensibility, and we should consider this when making decisions on the topic. Related ticket is #35607. I have some concrete thoughts on this and maybe we can schedule a chat or open office hours or similar to go over this?
(We could also incorporate into the chat Document StorageHandler as public API. which is in my inbox, waiting, with a big red PENDING label.)