Added a comment

1 files changed, 20 insertions, 0 deletions

diff --git a/doc/bugs/windows_port_-_can__39__t_directly_access_files/comment_2_c65e5491c82908af46fe2c97e048d210._comment b/doc/bugs/windows_port_-_can__39__t_directly_access_files/comment_2_c65e5491c82908af46fe2c97e048d210._comment
new file mode 100644
index 000000000..3368e3a31
--- /dev/null
+++ b/doc/bugs/windows_port_-_can__39__t_directly_access_files/comment_2_c65e5491c82908af46fe2c97e048d210._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-06-14T15:40:04Z"
+ content="""
+Your transcript shows `git annex get` apparently receiving the file. I don't see how that could possibly have worked if git-annex-shell were not in the path on the server, since that is the command it runs to send the file. Also, `git annex copy` is earlier used to send the file to origin, which again should not work if git-annex-shell was not in the path. I think this whole git-annex-shell not in path thing is a red herring.
+
+What actually appears to be going on is this:
+
+1. You create a new empty repository. Since this is Windows, it's forced into direct mode.
+2. You manually merge origin/synced/master into this repository. Bypassing `git annex sync` in this way means that direct mode mappings are not updated for the files contained in that branch.
+3. You run `git annex get` on a file from that branch. The file is retrieved. Since no direct mode mapping exists for the object it just retrieved, it stashes it in .git/annex/objects and the file is left with the fake symlink git uses on windows.
+
+The manual merge in step 2 is the cause of the problem. The [[direct_mode]] documentation advises against using git commands that update the repository tree because it can lead to this kind of problem (as well as more serious data loss).
+
+Of course, you had no choice but to merge from origin/synced/master, because git annex sync didn't push to origin/master, so simply cloning the bare repository wouldn't work. However, I did fix that a few days ago.
+
+I see this as more evidence of there needing to be a [[todo/direct_mode_guard]] to block users from running unsafe git commands in direct mode repositories. This bug probably can be closed, assuming I correctly understand what happened.
+"""]]