You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The intentional design currently accommodates specific edge cases concerning the auto-deletion of R2 files. For instance, if an image is embedded across multiple websites and is inadvertently overlooked, deleting the image (as a result of removing an associated item) will lead to broken links, resulting in 404 errors.
Retaining files on R2, S3, or other storage engines is generally not a concern in today's context, given the abundance of storage space and typically small file sizes. While a large accumulation of such undeleted files could potentially become an issue, engineering often requires making trade-offs. It is acceptable to intentionally leave certain imperfections unaddressed, prioritizing time for more urgent or important matters, and maintaining an overall simple implementation, which facilitates straightforward troubleshooting.
In the future, we plan to develop a separate media manager that will allow for the direct deletion or movement of files on R2: #39
@wenbinf, your remark about trade-offs is insightful. Still, I can think about a couple of use cases for deletion. One is the need to respond to take-down requests that may have legal consequences. Another would be for uploads whose item is never completed (Create button never pressed but potentially large object never seen by anyone).
It's hard to find an object to delete from the Cloudflare R2 objects dashboard, as the objects are listed alphabetically and Microfeed objects receive random-ish ids.
not sure if it is a bug or a feature request :|
The text was updated successfully, but these errors were encountered: