comments

doc/bugs/importtree_with_versioning__61__yes__58___check_first/comment_2_482b88a01eb307794c1dd3f9ce8d7938._comment

@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2024-11-12T17:35:16Z"
+ content="""
+Made a pull request to aws <https://github.com/aristidb/aws/pull/292>
+
+(As sometimes S3 maintainer of aws, I'll probably accept it if nobody
+objects to it.)
+"""]]

doc/bugs/importtree_with_versioning__61__yes__58___check_first/comment_3_76df8f40ff2fa1f5429e31ecedba6090._comment

@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2024-11-12T17:35:50Z"
+ content="""
+Wait though... We have signature=anonymous. So git-annex does in fact know
+that this special remote is read-only. git-annex will never try to write to
+it (even if the bucket somehow allowed anonymous writes) as long as it's
+configured with signature=anonymous.
+
+So, it could just avoid trying to set versioning when signature=anonymous,
+and assume the bucket has versioning enabled.
+
+Hmm, in lockContentS3, when versioning is enabled, it calls
+checkVersioning, which checks if a S3 version ID has been recorded for the
+file. What if the bucket did not actually have versioning enabled? Then an
+import from it would not record a S3 version ID. That would make this, and
+other places like checkKey that expect versioned buckets to have S3 version
+IDs fail in unexpected ways.
+
+So, I guess I'm inclined to not go down this read-only path, and instead wait for
+aws to get updated and use that.
+"""]]