Open 4o4x opened 4 months ago
I wrote a script to observe how the sync command behaves with Glacier objects in AWS CLI. I used these flags in every possible combination:
The most important result obtained:
If the object in the source bucket is a Glacier object, no matter which flags are used, we cannot do anything to the object. Here are the test results:
I wrote a script to observe how the sync command behaves with Glacier objects in AWS CLI. I used these flags in every possible combination:
- --delete
- --ignore-glacier-warnings
- --force-glacier-transfer
- --storage-class=STANDARD | GLACIER
The most important result obtained:
If the object in the source bucket is a Glacier object, no matter which flags are used, we cannot do anything to the object. Here are the test results:
Thank you for your efforts on this. What happens if the src or dst object's storage class is glacier deep archive
? Does GLACIER
also covers DEEP ARCHIVE
?
@4o4x could you take a look at the PR description if it's still correct after the review changes please? thanks.
@4o4x could you take a look at the PR description if it's still correct after the review changes please? thanks.
I have removed compare strategy part 👍
@sonmezonur @ilkinulas PTAL
@ilkinulas @sonmezonur PTAL
This pull request addresses a bug (#712) in the sync command where objects in Glacier storage at the destination were being overwritten during synchronization. closes #712
Bug Details:
During the sync process, if an object exists in both the source and destination, and the destination object is in Glacier storage, it was incorrectly being overwritten by the source object.
Fixes:
Previously, if either the source or destination object was in Glacier storage, it was skipped. In the new version, only the source object is skipped, but the destination object is not. If the destination object is skipped, it will be considered as only in the source during the comparison phase, leading to it being overwritten by the source object.