blob: 432c72083ba90a5b3baf995bd0770546b68dba98 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
|
### 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.
> Fixed both bugs. You should be able to upgrade git-annex and re-run the command
> and end up with a working direct-mode repository. [[done]] --[[Joey]]
|
