Even with AWS_S3_FILE_OVERWRITE set to False, files may still get overwritten in race condition situations. This is arguably very rare and mostly a problem in multi-server situations, but it means this setting provides a false sense of security.
S3Storage.get_available_name defers to Storage.get_available_name. This in turn uses a simple while self.exists check, and S3Storage.exists just queries the S3 API. Since this is sufficiently laggy, a classic race condition is possible:
- [Process 1]
.exists? → No
- [Process 2]
.exists? → No
- [Process 1]
._save
- [Process 2]
._save
I'm not sure what the solution to this would be. The S3 API would need to provide some way to fail the upload if the file already exists, and this library would need to use it; but I'm not sure the S3 API has such a thing.
If this can't be avoided entirely, at least a warning should be added to the documentation, and the use of UUIDs encouraged, or something like that.
Even with
AWS_S3_FILE_OVERWRITEset toFalse, files may still get overwritten in race condition situations. This is arguably very rare and mostly a problem in multi-server situations, but it means this setting provides a false sense of security.S3Storage.get_available_namedefers toStorage.get_available_name. This in turn uses a simplewhile self.existscheck, andS3Storage.existsjust queries the S3 API. Since this is sufficiently laggy, a classic race condition is possible:.exists? → No.exists? → No._save._saveI'm not sure what the solution to this would be. The S3 API would need to provide some way to fail the upload if the file already exists, and this library would need to use it; but I'm not sure the S3 API has such a thing.
If this can't be avoided entirely, at least a warning should be added to the documentation, and the use of UUIDs encouraged, or something like that.