mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

enableremote S3: Do not let versioning=yes be set on existing remote

Browse source 
Because when git-annex lacks S3 version IDs for files stored in the bucket,
deleting them would cause data loss.

Also because git-annex is not able to download unversioned objects from a bucket
when versioning=yes.

This also prevents setting versioning=no. While that would perhaps be
possible to do safely, it would add complexity, and would mean that if
the user accidentially did enableremote versioning=no, they would not be
able to undo it.

This commit was sponsored by Trenton Cronholm on Patreon.
This commit is contained in:
Joey Hess 2019-01-29 14:08:42 -04:00
parent ee011b3cbb
commit bb9817ceae
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 38 additions and 45 deletions
Download patch file Download diff file Expand all files Collapse all files

27
doc/bugs/potential_data_loss_after_late_enabling_of_S3_versioning.mdwn
View file

@ -35,26 +35,17 @@ only place a file was stored, they would lose data without git-annex being
run at all, so it's equivilant to them deleting the bucket, so this seems
not something it needs to worry about).
There is [an yet-unmerged pull
request](https://github.com/aristidb/aws/pull/255) to let buckets be
created with versioning enabled, that is kind of a prerequisite for this
change, otherwise the user would need to manually make the bucket and
enable versioning before initremote.
So, plan:
Plan:
* Wait for the PutBucketVersioning pull request to be merged.
* Add a remote.name.s3-versioning-enabled which needs to be true
in order for exporttree to remove files from a versioned remote.
* Enable versioning and set remote.name.s3-versioning-enabled during initremote,
when versioning=yes. If aws library is too old to enable versioning,
initremote should fail.
* Do no allow changing versioning= during enableremote.
* Any repos that used versioning=yes before this point will see removal
of files from them fail. The user can either manually set
remote.name.s3-versioning-enabled (if they are sure they enabled it from
the beginning), or can disable versioning. (Or perhaps other resolutions
to the problem, up to the user.)
(Done, not in a release yet, but will probably be aws-0.22)
* Auto-enable versioning during initremote (and not enableremote)
when versioning=yes. (Or prompt user to do it when aws is too old.)
(Done)
* Do not allow changing versioning= during enableremote.
* Any repos that previously enabled versioning after storing some
unversioned files still are at risk of data loss. Detect this
case and treat them as versioning=no. How?
# change exporttree