Please describe the problem.
I added some metadata to my music repository and tried a metadata-driven view.
git annex view composer=* performer=
When I wanted to return to the original list of directories and files, that fails. I now only see a list of directories that contain files which are actually on my laptop, and the generated views.
When I did git annex vpop, I got the following:
frederik@freo:~/Music$ git annex vpop
vpop 1
error: Your local changes to the following files would be overwritten by checkout:
Mozart, Wolfgang Amadeus/Academy of St. Martin in the Fields/01. Wolfgang Amadeus Mozart - Serenade No. 10 in B-flat major, KV 361 _Gran Partita_ - Ia. Largo_%Wolfgang Amadeus Mozart - Serenade No. 10 in B-flat major, KV 361 _Gran Partita_ (Academy of St. Martin in the Fields feat. conductor - Sir Neville Marriner)%.flac
Mozart, Wolfgang Amadeus/Academy of St. Martin in the Fields/02. Wolfgang Amadeus Mozart - Serenade No. 10 in B-flat major, KV 361 _Gran Partita_ - Ib. Allegro molto_%Wolfgang Amadeus Mozart - Serenade No. 10 in B-flat major, KV 361 _Gran Partita_ (Academy of St. Martin in the Fields feat. conductor - Sir Neville Marriner)%.flac
I had not actually altered any of these files. I merely cd'd into the directory and did an ls to see what it looked like.
The view is also not generated correctly, as re-running
git annex view composer=* performer=
gives me a list of directories with several directories that should not be present in the view.
So far, I'm unable to go back to the original state.
What version of git-annex are you using? On what operating system?
Debian/Jessie
git-annex version: 5.20141125 build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external local repository version: 5 supported repository version: 5 upgrade supported from repository versions: 0 1 2 4
You should be able to get back to the original state (in terms of working directory) by checking out the 'master' branch (or whatever branch you started the view from):
Oh, you may also need to clean up directories files left over from the view with:
This will remove everything not ignored or tracked!
The only way I can reproduce this is if I use
git annex edit
while inside the view.It might be that there's some kind of unclean git tree that can cause a problem when entering a view, but I was not able to find one.
Please provide clear instructions how to reproduce this problem.
OK, when I try git checkout master, it fails with some of these errors:
These filenames have been created by git annex when creating the view. The original one is rather long too:
In directory:
It looks like this has something to do with the problem.
When I do git clean -fd, I only have the 2 directories left as created by the view. I still can't do git annex vpop anymore, as the reply is that I'm not in a view anymore.
Some more info on that one file:
I can at least reproduce the error.
http://stackoverflow.com/questions/6571435/limit-on-file-name-length-in-bash
In my case, I cannot create the file because the filename is 262 bytes long, and either ext3 or bash have a filename limit of 255 bytes.
You may have to delete it using its inode or the "rsync --delete with empty directory" trick to get rid of it. Odd how git-annex managed to create it in the first place though..
If I were in this situation, I would clone the broken repo, check the symlinks look correct in the clone, 'git annex reinit' it with the broken repos UUID, move .git/annex/objects to the clone, fsck and replace the broken one with the clone (just move the broken one aside if you want to keep it around).
I don't think you can lose any data this way. Though any files you added while in the view (which you shouldn't do anyway) will be present in the annex, but have no symlink (they will show up in 'unused').