summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2013-04-10 19:57:50 -0400
committerGravatar Joey Hess <joey@kitenet.net>2013-04-10 19:57:50 -0400
commit5b1c85517c9933e26d50a072f104f7afaa845267 (patch)
tree1426f303b9a5482200748b91aeae4a5ff18e7222
parentb6963a83f35c7162286ac14cafeb5cc29f8ea7c6 (diff)
parentda40f4a8021d2e40e052b9b6a63af2ecd950298f (diff)
Merge branch 'master' of ssh://git-annex.branchable.com
-rw-r--r--doc/bugs/Add_another_repository_on_USB_drive_causes_sync_loop/comment_4_1f08fd5dd4f5d8723c2b5391cc3b60f9._comment22
1 files changed, 22 insertions, 0 deletions
diff --git a/doc/bugs/Add_another_repository_on_USB_drive_causes_sync_loop/comment_4_1f08fd5dd4f5d8723c2b5391cc3b60f9._comment b/doc/bugs/Add_another_repository_on_USB_drive_causes_sync_loop/comment_4_1f08fd5dd4f5d8723c2b5391cc3b60f9._comment
new file mode 100644
index 000000000..6c5d259f2
--- /dev/null
+++ b/doc/bugs/Add_another_repository_on_USB_drive_causes_sync_loop/comment_4_1f08fd5dd4f5d8723c2b5391cc3b60f9._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 4"
+ date="2013-04-10T22:58:07Z"
+ content="""
+Accessing files from USB on Windows is in scope, but it needs a windows port. Then you could just run git-annex on windows and it would pull the files from USB into your main repository, like the assistant does now on Mac and Linux.
+
+-----
+
+I suspect you don't have actual irreparable data loss. Or, perhaps not. If you really need to get that data back I can try to help.
+
+As I understand what happened, files were sent over the the USB drive, and you had another assistant running in that repository. It seems to have done something wrong, and taken the 1-line standin files that git uses to represent symbolic links when on a FAT filesystem, and committed those to the annex. These new files were then sent back to your original repository.
+
+So, if you look at `git log --status`, you'll find a commit that touched every file, and if you `git revert` that commit, the tree would be returned to how it was before that rogue assistant chomped on it. The actual contents of the files, which is stored in the annex, will probably then have not been lost. Although if you're using direct mode for your repository it is possible to lose annexed content if a file is overrwitten by a newer version, so I can't guarantee that 100%, like I could for indirect mode.
+
+Anyway, I need to fix this misbehavior of the assistant when run on a FAT filesystem, it seems.
+
+------
+
+I have reproduced the bug that the assistant, in a FAT filesystem, commits symlink standin files. It seems to do this at least at startup, to all such standin files. Oddly, I did not see this behavior before when using the assistant on FAT filesystems on Android.
+"""]]