In our situation, we have a site being migrated to Drupal, which already has their images and videos in an S3 bucket. The bucket is huge - we've already moved beyond testing with a subset in a different bucket, and are testing with an ostensibly-but-apparently-not-actually-readonly access key with the "real" bucket. In testing data migration in particular, we do many imports and rollbacks, the latter of which will make unlink requests - which, while testing, we do *not* want to be honored. Therefore, for debugging purposes, it's helpful to only pretend we've deleted physical files, while leaving them in place for the next round of migration import testing.
Note: we don't have a strong need for this to actually be committed - we most likely will be past the testing phase by the time this shows up in a release anyway, but for now putting the patch up here and referencing it in composer.json serves our needs.
Add a "disable_delete" option to the settings form - when this is turned on, the stream wrapper unlink() simply returns TRUE without doing anything.
Review the patch.
Checkbox added to the settings form.
None.
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | s3fs-2984268_disable_delete_5.patch | 2.31 KB | geoffreyr |
| #3 | s3fs-disable-delete-3.patch | 2.25 KB | mikeryan |
| s3fs-disable-delete.patch | 1.8 KB | mikeryan |
Comments
Comment #3
mikeryanComment #4
mikeryanWell, we did finally figure out the right incantation to get keys providing puttable-but-not-deletable permissions, so we're no longer using this. Downgrading but leaving here, it might be helpful for quickly temporarily disabling deletion. No worries if the maintainers say "Closed (won't fix)".
Comment #5
geoffreyr commentedRerolled against latest 8.x-3.x-dev.
Comment #6
cmlaraI would rather we keep ACL control at the bucket instead of inside S3FS, closing in favor of the approach proposed in #3185760: Allow read only use of S3 bucket.