- 最新
- 投票最多
- 评论最多
Hello,
I understand you have a question about S3 lifecycle policies.
According to the S3 Lifecycle Policy documentation on AWS Docs [1], you can use Expiration actions. These actions define when objects expire. Amazon S3 deletes expired objects on your behalf asynchronously. With S3 Lifecycle configuration rules, you can tell Amazon S3 to transition objects to less-expensive storage classes, or archive or delete them. However, this alone does not solve your problem since, as you said, policies only allow you to delete objects from its creation date.
Per rePost-User-2738569, this is where versioning comes in. If you set a lifecycle policy with bucket versioning enabled, every time a user changes an object, the object gets a new "version id". This becomes the newest version of the object and the main one that the user will see. You can set the number of days for when a object becomes noncurrent, and the number of newer versions to retain. That way, even though a number of objects are noncurrent, only the number of objects you specify will be retained.
Thus, you can set the number of days for expiration to be 90. You can set final deletion for 90 days this way as well.
But the file will never be versioned, it's uploaded and then deleted but nothing happens between this two events. If versioning is enabled i will always have one version (current version) so if delete the file the problem remain the same ?
How about i add a to_delete tag and a to_delete metadata when the user wants to deletes the file. If my understanding is correct, if a file metadata is added aws creates a copy of the file which would resolves the problem of the creation date ?
Have you enabled versioning? And is the modified object name going to remain the same?
No bucket versioning is not enabled and yes the modified object will still have the same name