Please describe the problem.
I'm using git-annex v6 in windows and seems git annex get
fails.
Deleting the pointer files and doing a hard reset seems to fix the problem.
Another bug report named "v6 repo can not restore files with executable permission" seems to point to the same problem but a little different.
[[!retitle "git annex get fails sometimes in v6 repository on Windows"]]
What steps will reproduce the problem?
I have a repo in D:\annex with a file test
Now I create another repo:
$ cd H:\annex
$ git init
Initialized empty Git repository in H:/annex/.git/
$ git annex init "portable drive"
init portable drive
Detected a filesystem without fifo support.
Disabling ssh connection caching.
Detected a crippled filesystem.
Enabling direct mode.
ok
(recording state in git...)
$ git annex upgrade
upgrade . (v5 to v6...)
Upgraded repository out of direct mode.
Changes have been staged for all annexed files in this repository; you should run `git commit` to commit these changes.
Any other clones of this repository that use direct mode need to be upgraded now, too.
ok
$ git remote add laptop D:/annex
$ git annex sync
commit ok
pull laptop
warning: no common commits
remote: Counting objects: 21, done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 21 (delta 3), reused 0 (delta 0)
Unpacking objects: 100% (21/21), done.
From D:/annex
* [new branch] git-annex -> laptop/git-annex
* [new branch] master -> laptop/master
* [new branch] synced/git-annex -> laptop/synced/git-annex
* [new branch] synced/master -> laptop/synced/master
Already up-to-date.
ok
(merging laptop/git-annex laptop/synced/git-annex into git-annex...)
(recording state in git...)
push laptop
Counting objects: 8, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (8/8), 928 bytes | 0 bytes/s, done.
Total 8 (delta 0), reused 0 (delta 0)
To D:/annex
c1aee82..980dc01 git-annex -> synced/git-annex
ok
$ git annex get .
get test (from laptop...)
SHA256E-s14488367--4391729b982439764813156e1bfc12e9626ae89452ab812f5180c376fbd57fc0
14,488,367 100% 63.24MB/s 0:00:00 (xfr#1, to-chk=0/1)
(checksum...)
git-annex: DeleteFile ".\\test": permission denied (The process cannot access the file because it is being used by another process.)
failed
git-annex: get: 1 failed
It seems to try to delete the pointer file, but finds the file in use. Maybe fsck is using it?
$ cat test
/annex/objects/SHA256E-s14488367--4391729b982439764813156e1bfc12e9626ae89452ab812f5180c376fbd57fc0
$ git annex lock
lock test git-annex: content not present; cannot lock
And git annex unlock
will do nothing.
If you can't reproduce the problem, I'll run the tests for you.
What version of git-annex are you using? On what operating system?
Latest compile from source, Windows 8.1
I think I found the problem:
After I edit the file and commit, if I lock the file and commit again, the problem won't happen.
I thought there shouldn't be a difference between committing a locked file and an unlocked file?
There is another problem too: When you unlock the file, git thinks you changed it. Maybe you could fix this too?
Note that v6 mode is still considered experimental.
I know that I saw a problem like this, where git-annex was reading the pointer file and didn't always get around to closing it before it tried to replace it. I thought I fixed it back in February though -- but that fix may have bit rotted; looking at the current code, I think it could leave the file open until a GC pass, so if the GC doesn't always run in time, that could explain the reported indeterminacy.
Please paste the actual version of git-annex you're using, "latest build from source" is a little bit vague.
Since you are building from source, you might try pulling; I've made a change that may fix it again.
It's 6.20160401-g083dd8f, Sorry for the delay. And btw my v6 repo is not in adjusted mode. But I think adjusted mode has the same problem too.
I pulled and checked 6.20160408-gf970490.
There are several problems now:
sync
on a new repo itget
s all the filesdrop
doesn't drop the filelock
doesn't workget
really fixed because it isn't neededBtw, look at my comment on /todo/smudge (maybe put on a wrong page)
I think using hardlinks on windows can fix many problems here ( adjusted/direct mode which I hate )
And it should need little work as tools already accept it on windows
I'll put all the commands needed to reproduce the problem: