From d98a7f0afc50c2dce0424941936c04c851c16d69 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 1 May 2023 13:09:47 -0400 Subject: [PATCH] comment --- ..._221e01e024595f444e629db510eb60be._comment | 22 +++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 doc/forum/git_annex_sync_update_remote/comment_4_221e01e024595f444e629db510eb60be._comment diff --git a/doc/forum/git_annex_sync_update_remote/comment_4_221e01e024595f444e629db510eb60be._comment b/doc/forum/git_annex_sync_update_remote/comment_4_221e01e024595f444e629db510eb60be._comment new file mode 100644 index 0000000000..ec403fc301 --- /dev/null +++ b/doc/forum/git_annex_sync_update_remote/comment_4_221e01e024595f444e629db510eb60be._comment @@ -0,0 +1,22 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 4""" + date="2023-05-01T17:02:17Z" + content=""" +One way is to run this on your system: + + git-annex drop foo.h5 --from cluster + +If you really have a reason to want to run `git-annex drop` on the cluster +itself, it needs to be able to connect back to your system in order to to +verify that your system still has a copy of the file it's dropping. + +Imagine what would happen if you ran `git-annex drop` of the same file on +your system and on the cluster at the same time, if that check were not +done. The file would be dropped from both places and so you'd lose data. + +You can use `git-annex drop --force` on the cluster if you're sure that +your system still has the content. But it's probably going to be better to +just use `git-annex drop --from cluster` run on your system, which avoids +the potential for a mistake causing data loss. +"""]]