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 2013-10-26 15:30:44 -04:00
commit d3fbb8acd5
3 changed files with 50 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

21
doc/bugs/Corrupted_drive:_Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_1_80ca50f5305eda71fe32f2b0bc922c34._comment Normal file
View file

@ -0,0 +1,21 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.47"
subject="comment 1"
date="2013-10-26T19:22:57Z"
content="""
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 is `git annex indirect` and `git 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:
git annex whereis $somefile
git annex get $somefile
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\"
"""]]

19
doc/bugs/directory_remote_+_shared_encryption_+_chunk_size___61___lost_files__63__/comment_1_69dfbf566c75396cdaaf5ad70f1a94a8._comment Normal file
View file

@ -0,0 +1,19 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.47"
subject="comment 1"
date="2013-10-26T19:06:38Z"
content="""
There was a bug that caused it not to write the chunkcount file.
I have fixed it, and put in a workaround so fsck, etc, will
see that the file is stored on the remote despite there being no
chunkcount file present.
I was initially puzzled by your output showing the chunkcount file being present.
However, the bug also caused it to write a chunkcount file when chunking was disabled (ie, the logic for when to write the file was inverted).
So, I think that the ls you show is after you set up the remote without specifying chunk size, and copied a file to it.
Please test with the next autobuild of git-annex (should be one within an hour my my posting this comment) and verify it can now see the files you stored on the remote with chunking.
"""]]

10
doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__/comment_4_ac65028203ff0cbdb978200235fb4e9c._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.47"
subject="comment 4"
date="2013-10-26T19:26:22Z"
content="""
I have moreinfoed this bug, until I hear back with a better problem description.
Using `git log --stat` to investigate any commits where files were removed would probably be a useful way to get a handle on what happened.
"""]]