diff options
3 files changed, 50 insertions, 0 deletions
diff --git a/doc/bugs/Corrupted_drive:_Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_1_80ca50f5305eda71fe32f2b0bc922c34._comment b/doc/bugs/Corrupted_drive:_Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_1_80ca50f5305eda71fe32f2b0bc922c34._comment new file mode 100644 index 000000000..e47cbd327 --- /dev/null +++ b/doc/bugs/Corrupted_drive:_Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_1_80ca50f5305eda71fe32f2b0bc922c34._comment @@ -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\" +"""]] diff --git a/doc/bugs/directory_remote_+_shared_encryption_+_chunk_size___61___lost_files__63__/comment_1_69dfbf566c75396cdaaf5ad70f1a94a8._comment b/doc/bugs/directory_remote_+_shared_encryption_+_chunk_size___61___lost_files__63__/comment_1_69dfbf566c75396cdaaf5ad70f1a94a8._comment new file mode 100644 index 000000000..e068501ad --- /dev/null +++ b/doc/bugs/directory_remote_+_shared_encryption_+_chunk_size___61___lost_files__63__/comment_1_69dfbf566c75396cdaaf5ad70f1a94a8._comment @@ -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. + + +"""]] diff --git a/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__/comment_4_ac65028203ff0cbdb978200235fb4e9c._comment b/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__/comment_4_ac65028203ff0cbdb978200235fb4e9c._comment new file mode 100644 index 000000000..be972fa9a --- /dev/null +++ b/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__/comment_4_ac65028203ff0cbdb978200235fb4e9c._comment @@ -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. +"""]] |