Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Same steps and scenario as above (except with Amazon S3 instead of DreamObject).
Create new Storage Class and Amazon container
Set the storage class's Amazon container to Propagate=Yes and Serve=Yes.
Add the class to a node's file/image field.
Upload files to node, save and run cron
Everything works as intended (files moved to Amazon and links are updated).
Set the Amazon container to External=Yes (OR set the class's container's Propagate to No).
The existing files already on Amazon still work correctly.
Any new files added to the field go to the initial container (Filesystem) as intended.
When Cron is run, All the new files are physically deleted and cannot be recovered.
This seems to be an issue beyond the External setting as the same issue happens when there is only one class container and it's Propagate is turned off.
There should be a check to ensure that when deleting a file from a container, that it at least exists elsewhere (including the initial container)
Comments
Comment #1
nimzie CreditAttribution: nimzie commentedsubscribing
Comment #2
tannerg CreditAttribution: tannerg commentedsubscribing
Comment #3
Perignon CreditAttribution: Perignon commentedNew version of Storage API is being released right now. Can you re-confirm this as an issue?
So far I have not seen this happen but that does not mean this isn't true.
Comment #4
mdolnik CreditAttribution: mdolnik commentedI can confirm this is still an issue in 7.x-1.8.
Same steps and scenario as above (except with Amazon S3 instead of DreamObject).
This seems to be an issue beyond the External setting as the same issue happens when there is only one class container and it's Propagate is turned off.
There should be a check to ensure that when deleting a file from a container, that it at least exists elsewhere (including the initial container)