This commit is contained in:
https://www.google.com/accounts/o8/id?id=AItOawn3m4J087saKH761otsxmTtQdme8mWL0Uc 2013-01-18 10:46:35 +00:00 committed by admin
parent 297104088f
commit 299aeca177

View file

@ -0,0 +1,47 @@
### What steps will reproduce the problem?
How to reproduce:
1. Check that the files involved are not available in the local repository.
2. Force a switch to direct mode to fail, for example, due to a 'exotic' filename
(first bug).
3. Solve that problem.
4. Make another switch to direct mode, but call that command in a subdirectory of
the git-tree. Which will because some annexed file does not exists (second bug).
Note: all subsequent switches to direct mode will now fail, no matter where started.
Example:
mkdir test1 test2 && cd test1 && git init . && git annex init
mkdir umlaut something\ else
date > umlaut/this_has_a_$'\201'
date > something\ else/problem
git annex add .
git commit -m "Init"
cd ../test2/
git clone ../test1/ . && git annex init
git annex move --from origin .
cd ../test1/
git annex direct #aborts with: commitBuffer: invalid argument (invalid character)
cd umlaut
git mv this_has_a_$'\201' this_has_a_o
git commit -m "fix"
git annex direct # fails with getSymbolicLinkStatus: does not exist (No such file or directory)
### What is the expected output? What do you see instead?
Expected is a repository switched to direct mode.
The result is a repository which can't be switched to direct mode.
### What version of git-annex are you using? On what operating system?
git-annex version: 3.20130114
OS: Arch Linux (3.7.2-2-ck)
### Please provide any additional information below.
The second bug seams to be very specific about folder- and/or filename.
I believe that it has something to do with the space in the foldername.