Apologies--I did not read the changelog of more recent git-annex versions before reporting this bug, and I did not find any previous bug reports concerning this in BTS.
I just noticed that this issue has already been fixed in version 3.20120825. Also, I forgot to mention that the repositories in question were originally initialized in a Mac OS X machine using much newer git-annex version (I think 4.something), which seem to use the extension-preserving backend variants by default, unlike 3.20120629 in wheezy. However, given that git-annex repositories are often used in multiple machines running different operating systems and git-annex versions, it would be very nice if git-annex shipped in wheezy would be as compatible as possible, and would fully support the composite extensions. This bug does not cause irretrievable data loss, but when this happens with a repository that is the only copy, and the user don't know how to fix it (is there a command to move the .git/annex/bad files back into the original place automatically?), it can cause a lot of headache, and the output of annex-fsck looks very scary if you don't know what caused it, and that your files are still there, intact. If it's too late to get this fixed in wheezy, please feel free to close this bug (but I hope this will get fixed at least in 7.0.1). Anyway, am I correct in assuming that the workaround would be to use "git annex migrate" to move the troubled files to SHA256 backend without the E? Thanks, Henrik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
