Added a comment

1 files changed, 14 insertions, 0 deletions

diff --git a/doc/bugs/drop_fails_to_see_copies_that_whereis_sees/comment_1_f5a9d99d90daf5eba4773d361fa1807a._comment b/doc/bugs/drop_fails_to_see_copies_that_whereis_sees/comment_1_f5a9d99d90daf5eba4773d361fa1807a._comment
new file mode 100644
index 000000000..647c6db3a
--- /dev/null
+++ b/doc/bugs/drop_fails_to_see_copies_that_whereis_sees/comment_1_f5a9d99d90daf5eba4773d361fa1807a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.211"
+ subject="comment 1"
+ date="2013-01-08T18:43:33Z"
+ content="""
+So, the first part of this is git-annex behaving as designed. When there's a fatal disk problem and it cannot update its local location log, only the remote's location log gets updated. After a `git annex sync` (or your manual equivilant), the location log changes get propigated from the remote, and the local repository returns to a consistent state.
+
+As to the drop problem, look at it again. You have numcopies configured to 2, and there are currently 2 copies of the file. So dropping 1 would leave the numcopies constraint unsatisfied, and so it doesn't. You can override --numcopies 1 or --force the drop, but I don't see a bug here.
+
+(Perhaps the \"No other repository is known to contain the file.\" message is confusing in this context? It doesn't mean that no other repo has the file at all, but that there are no other repositories, that it was not able to check, that might have the file. If you had another removable drive with the file, and the drive was detached, this message would instead say \"Try making some of these repositories available: otherdrive\")
+
+(Re fscking in a bare repo, in a bare repository, you cannot fsck specific files/directories; fsck just checks every single key that git-annex knows about.)
+"""]]