1 files changed, 0 insertions, 53 deletions
diff --git a/doc/bugs/unlock_fails_silently_with_directory_symlinks.mdwn b/doc/bugs/unlock_fails_silently_with_directory_symlinks.mdwn
deleted file mode 100644
index 9b9bb6342..000000000
--- a/doc/bugs/unlock_fails_silently_with_directory_symlinks.mdwn
+++ /dev/null
@@ -1,53 +0,0 @@
-What steps will reproduce the problem?
-
-+    ```~/``` is tracked by git and git annex
-+    ```~/text/books/foo``` is annexed
-+    ```~/books``` is a symlink to ```text/books```
-+    from ```~/``` execute: ```git annex unlock books/foo```
-+    which returns immediately with zero exit code and does not unlock foo.
-
-What is the expected output? What do you see instead?
-
-+    I expect ```~/text/books/foo`` to be unlocked
-
-+    I think ```git annex unlock``` should resolve the symlinks and realize that this is a tracked file.
-
-What version of git-annex are you using? On what operating system?
-
-+    3.20121112 in debian unstable
-
-Please provide any additional information below.
-
-+    I can unlock foo if I provide the full path, eg:
-from ```~/``` execute: ```git annex unlock text/books/foo```
-
-+    Interestingly, the following _does_ successfully unlock the file: ```cd ~/books && git annex unlock foo```
-
-     So it seems that symlinks in $PWD are being resolved, but not those in file paths passed as arguments.
-
-Thank you, thank you!
-
-      - Jason
-
-jason@jasonwoof.com
-
-> I'm afraid this is not a bug. Here's why: If you run "git mv books/foo
-> books/bar", git will complain:
->
->> fatal: not under version control, source=books/foo, destination=books/bar
->
-> So git-annex is just following git's lead (indeed, it's just running
-> `git ls-files` to find files to act on), and git doesn't
-> recognise this path as a file that's in git. --[[Joey]] 
-
-+    Also, I think ```git annex unlock``` should emit an error message if a file explicitly addressed on the commandline can not be acted upon.
-
-> I'm beginning to think perhaps it should. Users seem to find the current
-> behavior to be sometimes confusing.
-> 
-> However, it's actually a very difficult change to make. Several commands
-> have multiple seek stages that act on different types of files, so
-> any warning printed by an earlier stage may be premature if a later
-> stage comes along and deals with a file. --[[Joey]]
-
->> Figured out a non-invasive way to add that warning. [[done]] --[[Joey]]