Please describe the problem.
On my raspberry pi, an SSH remote was in /var/lib/store (symlinked with /home/carlo/store), which contained a LVM volume spanning several USB drives. One of the drives got corrupted, which lead to this:
$ cd /home/carlo/store $ ls Input/Output Error
On my desktop machine, I then had a lot of transfers. After transfer, the file was turned into a symlink.
What steps will reproduce the problem?
- Create an annex and a remote ssh server.
- Simulate a corrupted drive for the remote, creating an input output error.
- Wait until the annex starts syncing on the desktop machine. If there were no further unidentified causes on my side, the assistant will start transfers that revert files to symlinks.
What version of git-annex are you using? On what operating system?
Ubuntu 12.04 64bit git annex 3.20121017 (from Ubuntu PPA)
Please provide any additional information below.
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
Please see [all my daemon.log](http://capocasa.name/daemon.tgz) files.
I noticed the problem yesterday afternoon (Thu 24 Oct).
# End of transcript or log.
moreinfo; either I don't have enough information to work on this, or it might have just been user error. --Joey
It seems to me that if a subdirectory of the repository is on a corrupted drive, and so it's not possible to list the files on it, this is basically the same as if you'd 'rm -rf' that subdirectory. So when it starts up, the assistant will see that these files are not present, and commit a removal to git.
Then when another machine syncs with that, it would delete the files from its repository too. However, it actually keeps the contents of the files stashed away in
.git/annex
. So to recover from this, all you have to do isgit annex indirect
andgit revert
the commit that deleted the files. All your files would then be available again.However, what you describe is instead that the assistant chose to drop the content associated with the files, but kept the symlinks for them checked into git. I don't understand why it would do that. Can you show the output of running, on the desktop machine:
Where $somefile is one of the files that has been reduced to a symlink.
Looking at your logs, they appear to be the logs from the server. The strange thing that appears in one of them is "git-annex: Not in a git repository." which was logged around 2013-10-24 20:07:25 CEST. I am not sure, but I think it might have been the rpi git-annex saying that, because there is also "fatal: '~/store/annex/' does not appear to be a git repository"
The assistant autorecovered my work repo before I noticed, so it looks like I can't provide the necessary info. There were a bunch of files missing that got re-synced from my home PC.
For what it's worth, I noticed that on my phone, when cutting the internet connection while syncing, the assistant downloaded existing files into placeholder files, and then continued actually downloading files when the network connection was restored.
I don't understand what you mean by "The assistant autorecovered my work repo before I noticed". What repo is the work repo, and how could the assistant "autorecover" it, and what did it do?
At this point, I am completely in the dark about whether you're reporting a problem, and what the problem is.
Sorry, missed the comment.
My work repo is the repository on my work laptop, where deletions got synced to.
Git annex had then run repository repair automatically, so the odd symlinks where no longer there for me to check out.
It is possible that I ran some git commands in direct mode I shouldn't have; I put the files back in and it's working nicely now. So this might have been a "no direct mode guard" issue.