From 9e901d326d06f49f43f24689b082684af38ebd3c Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 31 Jul 2024 10:04:08 -0400 Subject: [PATCH] comment --- ..._2e4920fb253c295e53ccb7573e178aaf._comment | 23 +++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 doc/bugs/Trust_but_Verify__58___RClone/comment_1_2e4920fb253c295e53ccb7573e178aaf._comment diff --git a/doc/bugs/Trust_but_Verify__58___RClone/comment_1_2e4920fb253c295e53ccb7573e178aaf._comment b/doc/bugs/Trust_but_Verify__58___RClone/comment_1_2e4920fb253c295e53ccb7573e178aaf._comment new file mode 100644 index 0000000000..8edabb5f7a --- /dev/null +++ b/doc/bugs/Trust_but_Verify__58___RClone/comment_1_2e4920fb253c295e53ccb7573e178aaf._comment @@ -0,0 +1,23 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2024-07-31T13:39:48Z" + content=""" +git-annex drop always actively verifies that a semitrusted remote +still has a copy of the file. + +How did you delete the file from the remote? I suppose it's possible that +rclone is seeing a cached or stale state of the dropbox. Or that the +dropbox you deleted it from was not in sync with the dropbox rclone was +looking at. + +What version of rclone? + +Here's the code that the rclone special remote uses to check the presence +of a file: + + +And at least according to the documentation of newObject, that does actively +check if the file is present: + +"""]]