summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2014-01-06 14:19:04 -0400
committerGravatar Joey Hess <joey@kitenet.net>2014-01-06 14:19:04 -0400
commit498a98dc5a811fd2a9854c818c7f536d9a8a437d (patch)
tree625b7106529e3bdbef2c9fc2b184c2ae5db033c9
parenteb743850ce9400038bb7a925ce5b893b9846d1a4 (diff)
parent61d34c5e50f729e1ab4abf2b39c0aa4f57458aee (diff)
Merge branch 'master' of ssh://git-annex.branchable.com
-rw-r--r--doc/bugs/Assistant_lost_dbus_connection_spamming_log/comment_3_10fa5082909f5e568623cf6d901d5161._comment11
-rw-r--r--doc/bugs/fatal:_git-write-tree:_error_building_trees/comment_2_77295c0b749e984a6fb200d3b73b5765._comment8
-rw-r--r--doc/bugs/gsha256sum_crashes/comment_4_1c46b4ad0c981c6105ffb8531223f0b1._comment10
-rw-r--r--doc/bugs/gsha256sum_crashes/comment_5_3fa106ed7fb30226ee7c48b66edb963c._comment16
-rw-r--r--doc/bugs/gsha256sum_crashes/comment_6_276b181b2aeb1512e0468b88598e0a84._comment12
-rw-r--r--doc/bugs/interference_with_Dropbox_results_in_data_loss.mdwn48
-rw-r--r--doc/bugs/interference_with_Dropbox_results_in_data_loss/comment_1_837c7ab2d31531ac8a61509225926814._comment20
-rw-r--r--doc/design/assistant/transfer_control/comment_3_44a1a6d2db9097de9ae68ea1ff1b08a2._comment8
-rw-r--r--doc/forum/Git_annex___39__corrupting__39___itself/comment_4_70e62e6fe75774a65b049c8f000dc6a3._comment8
-rw-r--r--doc/forum/How_do_I_do_with_.gitrefs__47_____63__.mdwn1
-rw-r--r--doc/forum/How_do_I_do_with_.gitrefs__47_____63__/comment_1_5e235af2ea13fd4f6a226c842f69965e._comment8
-rw-r--r--doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_4_99286f17a87049c303f2aa34c0a90286._comment13
-rw-r--r--doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_5_39bad7441dcea4da4b389700301233de._comment8
13 files changed, 171 insertions, 0 deletions
diff --git a/doc/bugs/Assistant_lost_dbus_connection_spamming_log/comment_3_10fa5082909f5e568623cf6d901d5161._comment b/doc/bugs/Assistant_lost_dbus_connection_spamming_log/comment_3_10fa5082909f5e568623cf6d901d5161._comment
new file mode 100644
index 000000000..249eb9c79
--- /dev/null
+++ b/doc/bugs/Assistant_lost_dbus_connection_spamming_log/comment_3_10fa5082909f5e568623cf6d901d5161._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.35"
+ subject="comment 3"
+ date="2014-01-06T16:22:49Z"
+ content="""
+Is dbus running at all?
+
+What is the frequency of the messages?
+
+"""]]
diff --git a/doc/bugs/fatal:_git-write-tree:_error_building_trees/comment_2_77295c0b749e984a6fb200d3b73b5765._comment b/doc/bugs/fatal:_git-write-tree:_error_building_trees/comment_2_77295c0b749e984a6fb200d3b73b5765._comment
new file mode 100644
index 000000000..dabc1d4f3
--- /dev/null
+++ b/doc/bugs/fatal:_git-write-tree:_error_building_trees/comment_2_77295c0b749e984a6fb200d3b73b5765._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.35"
+ subject="comment 2"
+ date="2014-01-06T16:14:29Z"
+ content="""
+As far as I can tell from git's code, this involves a \"cache-tree\" data structure stored in git's index file. git-annex has nothing to do with writing index files, beyond running git plumbing. So I don't see how this could be anything other than a corrupt index file (of a sort that git fsck doesn't detect), or a git bug. The best thing to do would be to send an example of a repository having this problem to the git developers for analysis.
+"""]]
diff --git a/doc/bugs/gsha256sum_crashes/comment_4_1c46b4ad0c981c6105ffb8531223f0b1._comment b/doc/bugs/gsha256sum_crashes/comment_4_1c46b4ad0c981c6105ffb8531223f0b1._comment
new file mode 100644
index 000000000..a188bf6f6
--- /dev/null
+++ b/doc/bugs/gsha256sum_crashes/comment_4_1c46b4ad0c981c6105ffb8531223f0b1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.35"
+ subject="comment 4"
+ date="2014-01-06T16:26:16Z"
+ content="""
+So far, only Jan has seen this problem, and it has affected both wget and gsha256sum.
+
+This makes me wonder if it's somehow a problem with running 64 bit code on his system.
+"""]]
diff --git a/doc/bugs/gsha256sum_crashes/comment_5_3fa106ed7fb30226ee7c48b66edb963c._comment b/doc/bugs/gsha256sum_crashes/comment_5_3fa106ed7fb30226ee7c48b66edb963c._comment
new file mode 100644
index 000000000..43ca8d31c
--- /dev/null
+++ b/doc/bugs/gsha256sum_crashes/comment_5_3fa106ed7fb30226ee7c48b66edb963c._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.35"
+ subject="comment 5"
+ date="2014-01-06T16:47:43Z"
+ content="""
+Searching for \"OSX SIGILL\" finds rather a lot of reports of problems like this.
+
+<http://trac.sagemath.org/ticket/12954>
+
+<http://stackoverflow.com/questions/20114920/can-an-exec-bad-instruction-sigill-on-dyld-my-fault>
+
+> My libraries were built using homebrew. By default homebrew optimizes for native architecture, resulting in machine instructions that don't work on older machines.
+
+Suggests to me that the OSX autobuilder probably needs to run the build with PATH set to a directory with un-optimised builds (or fat binary builds?) of all the utilities included in the app. Seems we're lucky and git-annex itself is not built with whatever sort of optimisations (SSE?) is causing this.
+"""]]
diff --git a/doc/bugs/gsha256sum_crashes/comment_6_276b181b2aeb1512e0468b88598e0a84._comment b/doc/bugs/gsha256sum_crashes/comment_6_276b181b2aeb1512e0468b88598e0a84._comment
new file mode 100644
index 000000000..9c0c40d67
--- /dev/null
+++ b/doc/bugs/gsha256sum_crashes/comment_6_276b181b2aeb1512e0468b88598e0a84._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.35"
+ subject="comment 6"
+ date="2014-01-06T18:01:43Z"
+ content="""
+I have updated the daily autobuild to use wget and coreutils (for gsha256sum) built using `brew install --build-bottle`. This should mean they are built portably without optimisations for the local CPU.
+
+That seems to be all the software on the build host that was installed using homebrew. So I hope the included rsync, curl xargs, etc are ok without being rebuilt.
+
+This all needs to be tested on a system affected by this problem..
+"""]]
diff --git a/doc/bugs/interference_with_Dropbox_results_in_data_loss.mdwn b/doc/bugs/interference_with_Dropbox_results_in_data_loss.mdwn
new file mode 100644
index 000000000..a60fd765e
--- /dev/null
+++ b/doc/bugs/interference_with_Dropbox_results_in_data_loss.mdwn
@@ -0,0 +1,48 @@
+### Please describe the problem.
+
+When working with git-annex in a folder managed by Dropbox, the folders names in .git/annex/objects/ are mangled by Dropbox. This leads to lost files.
+
+This is not a git-annex bug, but the problem is severe and it would be helpful when git-annex can deal with it somehow. Possibilities are:
+
+* include a warning in documentation (this will be probably found after someone encounters the problem actually)
+* issue a warning when running in a Dropbox managed folder
+* avoid using filenames that differs in case only (this would make git-annex also more robust against corruption i.e. when a repository is copied over filesystems/protocols without filename case support)
+
+Dropbox file name limitations: [[https://www.dropbox.com/help/145/en]]
+
+### What steps will reproduce the problem?
+ cd ~/Dropbox
+ mkdir test_annex
+ cd test_annex
+ git init
+ git annex init "test_annex"
+ cp ~/somefiles/* .
+ git annex add *
+ # wait for Dropbox to upload and mangle folder names in .git/annex/objects/
+ find -L . -type l | wc -l # print number of broken symlinks
+ git annex fsck # prints all the missing files
+
+
+### What version of git-annex are you using? On what operating system?
+
+* git-annex 3.20130207
+* Fedora 19
+
+### Please provide any additional information below.
+
+[[!format sh """
+# folder names mangled by Dropbox
+
+$ ls .git/annex/objects/
+Ff/ M9 (Case Conflict (1))/ x8 (Case Conflict (1))/
+Ff (Case Conflict)/ pF/ x9/
+Ff (Case Conflict (1))/ pF (Case Conflict)/ x9 (Case Conflict)/
+Ff (Case Conflict (2))/ pF (Case Conflict (1))/ Zf/
+Ff (Case Conflict (3))/ pF (Case Conflict (2))/ Zf (Case Conflict)/
+Ff (Case Conflict (4))/ pF (Case Conflict (3))/ Zf (Case Conflict (1))/
+Ff (Case Conflict (5))/ pF (Case Conflict (4))/ Zf (Case Conflict (2))/
+Ff (Case Conflict (6))/ PG/ Zf (Case Conflict (3))/
+...
+
+# End of transcript or log.
+"""]]
diff --git a/doc/bugs/interference_with_Dropbox_results_in_data_loss/comment_1_837c7ab2d31531ac8a61509225926814._comment b/doc/bugs/interference_with_Dropbox_results_in_data_loss/comment_1_837c7ab2d31531ac8a61509225926814._comment
new file mode 100644
index 000000000..256ae83b4
--- /dev/null
+++ b/doc/bugs/interference_with_Dropbox_results_in_data_loss/comment_1_837c7ab2d31531ac8a61509225926814._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.35"
+ subject="comment 1"
+ date="2014-01-06T16:02:45Z"
+ content="""
+I'm not seeing data loss. It looks like the contents of your files are still there, you just need to rename them back to the right directory names. If you're using indirect mode, you should be able to do this:
+
+ mv .git/annex/objects .
+ chmod -R u+w objects
+ git annex add objects
+
+That will re-inject all the file contents with the right names. You can then delete the objects directory, which should only contain symlinks at that point.
+
+----
+
+Moving git-annex to using lower case hash directories is on the very long term todo list, due to various crappy filesystems (problems mostly worked around by direct mode). Since it requires changing every symlink in every existing git-annex repository, which will be extremely disruptive, I'd need a much better reason than dropbox to do it now.
+
+I have no interest, in general, in making git-annex use filenames that meet whatever limitations dropbox wants to impose on its users.
+"""]]
diff --git a/doc/design/assistant/transfer_control/comment_3_44a1a6d2db9097de9ae68ea1ff1b08a2._comment b/doc/design/assistant/transfer_control/comment_3_44a1a6d2db9097de9ae68ea1ff1b08a2._comment
new file mode 100644
index 000000000..33ab5565b
--- /dev/null
+++ b/doc/design/assistant/transfer_control/comment_3_44a1a6d2db9097de9ae68ea1ff1b08a2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.35"
+ subject="comment 3"
+ date="2014-01-06T15:04:33Z"
+ content="""
+Just put the box.com remote in the transfer group. There is no need for special subdirectories, the transfer group makes the remote only want files that have not yet reached all the known clients.
+"""]]
diff --git a/doc/forum/Git_annex___39__corrupting__39___itself/comment_4_70e62e6fe75774a65b049c8f000dc6a3._comment b/doc/forum/Git_annex___39__corrupting__39___itself/comment_4_70e62e6fe75774a65b049c8f000dc6a3._comment
new file mode 100644
index 000000000..728b4d855
--- /dev/null
+++ b/doc/forum/Git_annex___39__corrupting__39___itself/comment_4_70e62e6fe75774a65b049c8f000dc6a3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.35"
+ subject="comment 4"
+ date="2014-01-06T16:16:08Z"
+ content="""
+This appears to be some form of corruption of git's index file. Someone will need to publish a git repository that has this problem in order for it to be investigated.
+"""]]
diff --git a/doc/forum/How_do_I_do_with_.gitrefs__47_____63__.mdwn b/doc/forum/How_do_I_do_with_.gitrefs__47_____63__.mdwn
new file mode 100644
index 000000000..d4a2a71b1
--- /dev/null
+++ b/doc/forum/How_do_I_do_with_.gitrefs__47_____63__.mdwn
@@ -0,0 +1 @@
+There is .gitrefs directory in my annexed repo while I am unaware. Should I do `git add .gitrefs/` or `git annex add .gitrefs/` or just ignore?
diff --git a/doc/forum/How_do_I_do_with_.gitrefs__47_____63__/comment_1_5e235af2ea13fd4f6a226c842f69965e._comment b/doc/forum/How_do_I_do_with_.gitrefs__47_____63__/comment_1_5e235af2ea13fd4f6a226c842f69965e._comment
new file mode 100644
index 000000000..9e8d044a1
--- /dev/null
+++ b/doc/forum/How_do_I_do_with_.gitrefs__47_____63__/comment_1_5e235af2ea13fd4f6a226c842f69965e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.35"
+ subject="comment 1"
+ date="2014-01-06T15:44:15Z"
+ content="""
+AFAIK neither git nor git-annex creates a .gitrefs directory.
+"""]]
diff --git a/doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_4_99286f17a87049c303f2aa34c0a90286._comment b/doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_4_99286f17a87049c303f2aa34c0a90286._comment
new file mode 100644
index 000000000..d21d87145
--- /dev/null
+++ b/doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_4_99286f17a87049c303f2aa34c0a90286._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.35"
+ subject="comment 4"
+ date="2014-01-06T15:48:36Z"
+ content="""
+@Tim, you do not seem to be having the problem that the OP described.
+
+It is completely normal for git-annex to represent a file whose content is not present in the repository as a broken symlink.
+Typically, git-annex preserves at least one copy of the file in one of your repositories. But if you `git annex add $file; git annex drop --force $file`, you will be left in exactly the situation you describe.
+
+You can use `git annex log $file` to see a log of which repositories contained a copy of the file in the past, and see what times the file was removed from each repository. This might give clues to what operation caused the last copy of the file to be lose.
+"""]]
diff --git a/doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_5_39bad7441dcea4da4b389700301233de._comment b/doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_5_39bad7441dcea4da4b389700301233de._comment
new file mode 100644
index 000000000..f7975fc0e
--- /dev/null
+++ b/doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_5_39bad7441dcea4da4b389700301233de._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkipQLNyt8RHREHpg2k5wdYeRSCCvSNSBg"
+ nickname="Tim"
+ subject="I'll start another thread"
+ date="2014-01-06T18:17:44Z"
+ content="""
+Let me start another thread then and not pollute this one. Thanks!
+"""]]