mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2019-10-15 11:46:22 -04:00
commit bfec5a2a41
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 97 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

56
doc/bugs/Windows__58___The_process_cannot_access_the_file_because_it_is_being_used_by_another_process.mdwn Normal file
View file

@ -0,0 +1,56 @@
### Please describe the problem.
I've had this problem intermittently through various versions of git-annex that use the filters. Just recently on the latest 7.20190912-g05bc37910, and only ever on windows.
Messages look like this:
```
git-annex.exe: .\2018/18-06-14 playcenter fun/18-06-14 playcenter fun_001[archer].jpg: DeleteFile "\\\\?\\D:\\Pictures\\Photos_again\\2018\\18-06-14 playcenter fun\\18-06-14 playcenter fun_001[archer].jpg": permission denied (The process cannot access the file because it is being used by another process.)
error: external filter 'git-annex smudge --clean -- %f' failed 1
error: external filter 'git-annex smudge --clean -- %f' failed
git status will show some files to be modified, since content availability has changed and git-annex was unable to update the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git status display, you can run: git update-index -q --refresh <file>
```
Essentially this will come up seemingly randomly when adding files, or when committing them. When it happens, git annex ends up in a strange state and often data is lost (the commit / additions continue despite errors and turn the affected files into the standin text files with paths to the content). It's scary enough, and unfortunately common enough, that I now make a copy of everything I add until I know for sure it has been successfully added and committed. My work around... is to delete failures, go to my copy, put it back and try adding it again (which may or may not work, due to the issue below).
What I have at the moment is an issue in which the file was added correctly (I can only assume... as it exists in the annex with the correct hash, and I've added it multiple times always resulting in the same one). I found/confirmed its location by following the hardlink (annex.thin is active) `fsutils hardlink list <file>`, so that worked. Yet fsck / whereis tells me it's not there. `git annex add <file>` was successful and `git commit -m "stuff"` completed "successfully" with the fail message above.
```
$ git annex info 18-06-14\ playcenter\ fun_001\[archer\].jpg
file: 18-06-14 playcenter fun_001[archer].jpg
size: 1.18 megabytes
key: SHA256E-s1177925--cf68e564a1505be3c609af97f80b77373264be399a5e5269ff20a43fe0f12e1d.jpg
present: false
```
Yet the file exists at `D:\Pictures\Photos_again\.git\annex\objects\403\52d\SHA256E-s1177925--cf68e564a1505be3c609af97f80b77373264be399a5e5269ff20a43fe0f12e1d.jpg\SHA256E-s1177925--cf68e564a1505be3c609af97f80b77373264be399a5e5269ff20a43fe0f12e1d.jpg` which to my naive eyes looks ok. Viewing the files content as well confirms it's correct visually (and again, it's hardlinked)
Yet...
```
$ git annex fsck 18-06-14\ playcenter\ fun_001\[archer\].jpg
fsck 18-06-14 playcenter fun_001[archer].jpg (checksum...)
** No known copies exist of 18-06-14 playcenter fun_001[archer].jpg
failed
(recording state in git...)
git-annex: fsck: 1 failed
```
Is this something you've seen before? As I currently have a repo in this state, if there are any commands I could run that might help illuminate the status of things let me know. Also if there are any secret ways to tell git annex "hey I know this exists, look again" that would be neat to know. ;)
Sorry I don't have more information at this stage. Please let me know how I can help out!
### What steps will reproduce the problem?
Unfortunately I have no way to reproduce. I've had it happen from time to time, so it is most definitely not a once off. I'm assuming it's some windows quirk as I've only ever seen it there.
### What version of git-annex are you using? On what operating system?
In this case "7.20190912-g05bc37910" but I seen it on earlier versions too. I think v6+. OS windows 8.1
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
Seriously. Git annex is amazing. I've used it for a bunch of things for a few years now and continue to love it. Outside of the issue above I have nothing but good things to say about it. My only hope is it continues to receive the love it has for years to come.
Thanks a lot everyone!

13
doc/bugs/Windows__58___The_process_cannot_access_the_file_because_it_is_being_used_by_another_process/comment_1_79c57a6a8c0b100c07d014d8d2b862cb._comment Normal file
View file

@ -0,0 +1,13 @@
[[!comment format=mdwn
username="jason.dixon.email@aa0e536a2ec2877d6f666108dbbc6e39bbe87ac0"
nickname="jason.dixon.email"
avatar="http://cdn.libravatar.org/avatar/fbe9050fc83bbd536d307d87ea14d4bc"
subject="One other thing to add"
date="2019-10-15T10:44:14Z"
content="""
I suppose one other thing I can add is that even within a command this is patchy. For instance in this commit of 16 files, 8 of them have this issue.
I can only assume there is some race condition in windows causing the process problem (but I don't want to assume too much).
I hope that helps, and I'm curious if anyone else has seen this.
"""]]

28
doc/forum/unable_to_access_remotes_when_cloning_a_gcrypt_remote.mdwn Normal file
View file

@ -0,0 +1,28 @@
I am following the guide on [Fully encrypted git repositories with gcrypt](https://git-annex.branchable.com/tips/fully_encrypted_git_repositories_with_gcrypt) to restore data to a new computer.
On my old computer, I was using a removable hard drive with a bare repo as my remote. Before migrating, I moved all contents to this repository.
I follow the relevant steps exactly:
```
git clone gcrypt::/media/me/path_to_repo clone
cd clone
git annex enableremote path_to_repo gitrepo=/media/me/path_to_repo
```
Now `git annex sync` reports success for both `origin` and `path_to_repo`. But `git annex sync --content` fails with:
Unable to access these remotes: path_to_repo
Try making some of these repositories available:
a3f8a46a-60fe-58e2-901b-2c093bcc22d3 -- [path_to_repo]
The sync with `origin` works, but as soon as it starts trying to get the content it reports the above.
`git annex get --from path_to_repo` reports no output.
Why does it say this when the repo is clearly available, seeing as I can do git annex sync? (at least -- as far as I can understand it ...)
I'm sorry I can't provide more detailed/to the point information. I am very befuddled by this behavior. Trying to understand how git annex works, I wonder if there is some information in my old 'checkout' repo which git annex needs to be able to recognize which repo is where? But my new clone has the correct repo uuid under the entry for `path_to_repo` in `.git/config`, so I don't understand why it doesn't know about it.
thanks!