aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2013-06-10 17:21:48 -0400
committerGravatar Joey Hess <joey@kitenet.net>2013-06-10 17:21:48 -0400
commitcc6b427497cd493a7d999e8670d2d21da7f1a332 (patch)
treec12ec18d3a2536e6ce002fc32cc46abb35b1296d
parent4eb26556d60ba74c033e2af0a1938ebd2ecbeb70 (diff)
parentaefe9bb78552950e6b1ce4222bf071e545d001de (diff)
Merge branch 'master' of ssh://git-annex.branchable.com
-rw-r--r--doc/bugs/Glacier_remote_uploads_duplicates.mdwn2
-rw-r--r--doc/bugs/Glacier_remote_uploads_duplicates/comment_6_feea067d6856af2840604782b29af86a._comment12
-rw-r--r--doc/bugs/Specifying_a_filename_starting_with___34__-c__34___instead_applies_it_to_all_files/comment_1_2fe6d735bc075275a6b8890fac48ee58._comment18
-rw-r--r--doc/bugs/encfs_accused_of_being_crippled/comment_1_5c5be012e1171ef108f38825d72791b6._comment23
-rw-r--r--doc/install/OSX.mdwn1
5 files changed, 56 insertions, 0 deletions
diff --git a/doc/bugs/Glacier_remote_uploads_duplicates.mdwn b/doc/bugs/Glacier_remote_uploads_duplicates.mdwn
index bcbd94815..f7c8c222e 100644
--- a/doc/bugs/Glacier_remote_uploads_duplicates.mdwn
+++ b/doc/bugs/Glacier_remote_uploads_duplicates.mdwn
@@ -29,3 +29,5 @@ However, whatever we do, it is impossible to map an "upload or overwrite on key
If the problem is as I think it is, always applying `--trust-glacier` should prevent the problem from occurring in most cases, since git-annex will run "checkpresent" and glacier-cli will confirm that the archive exists.
To fix the problem after it has occurred, it should be sufficient to delete duplicates using glacier-cli, since they _should_ be identical to each other. Some enhancement of the `glacier-cli archive list` command would help here.
+
+Update 10 June 2013: I've pushed a `glacier-cli` update and helper script in commit `b68835`. This adds a `--force-ids` option to `glacier archive list`, with which the helper script `glacier-list-duplicates.sh` uses to identify duplicates that can be removed. If you're affected by this issue, I suggest that you use this helper to identify and fix your problem by removing the duplicates. Please do so carefully by checking that the output of the helper is correct before you use it to delete the duplicates. See the comments at the top of the helper script for usage information.
diff --git a/doc/bugs/Glacier_remote_uploads_duplicates/comment_6_feea067d6856af2840604782b29af86a._comment b/doc/bugs/Glacier_remote_uploads_duplicates/comment_6_feea067d6856af2840604782b29af86a._comment
new file mode 100644
index 000000000..2a140eb49
--- /dev/null
+++ b/doc/bugs/Glacier_remote_uploads_duplicates/comment_6_feea067d6856af2840604782b29af86a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkexhIpGcYa22aPQtLm-StpHiF-MHYPh5w"
+ nickname="Robie"
+ subject="comment 6"
+ date="2013-06-10T17:24:34Z"
+ content="""
+This seems reasonable to me.
+
+One other possibility that you could end up with a duplicate: if `glacier-cli`'s cache is not up to date. For example: hosts A and B both have (the same) annex with the same Glacier special remote defined. Host A copies a file to Glacier. On host B, the `glacier-cli` cache doesn't know about the file, and so a copy to Glacier on host B also succeeds. When the cache is later brought up to date `glacier vault sync`, then the duplicate appears.
+
+I'm not sure what we can do about this. Perhaps we need to accept that duplicates will occur, and handle them more gracefully.
+"""]]
diff --git a/doc/bugs/Specifying_a_filename_starting_with___34__-c__34___instead_applies_it_to_all_files/comment_1_2fe6d735bc075275a6b8890fac48ee58._comment b/doc/bugs/Specifying_a_filename_starting_with___34__-c__34___instead_applies_it_to_all_files/comment_1_2fe6d735bc075275a6b8890fac48ee58._comment
new file mode 100644
index 000000000..39a469933
--- /dev/null
+++ b/doc/bugs/Specifying_a_filename_starting_with___34__-c__34___instead_applies_it_to_all_files/comment_1_2fe6d735bc075275a6b8890fac48ee58._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-06-10T20:30:27Z"
+ content="""
+This is the same as trying to rm a file named `-rf`
+
+In git-annex, as in git, -c sets a git configuration option. The text after the -c is supposed to be the option name and value. So -c-test is a valid command-line option.
+
+This leaves `git annex drop`, with no files specified to drop. As documented, git-annex commands default to acting on all relevant files in the current directory and subdirectories.
+
+Luckily, drop does check that numcopies other remotes have the file, so unless you also have a file named --force, you're not going to lose data doing this.
+
+I don't see any change I could make to prevent this kind of mistake. I checked and git also treats \"-c -test\" as valid input, despite \"-test\" not being a likely git config key (and no value being specified). I could make git-annex's option parser require the space between option and value (which git does require), which would perhaps reduce the set of files whose names are valid options.
+
+Fundamentally, this is a type of mistake that the design of unix command options allows to happen, if people use filenames starting with dashes -- so people generally don't do that. It's worth noting that git-annex is *very* careful itself, whenever passing a filename to a unix command, to check if it starts with a dash, and use \"./-file\" instead!
+"""]]
diff --git a/doc/bugs/encfs_accused_of_being_crippled/comment_1_5c5be012e1171ef108f38825d72791b6._comment b/doc/bugs/encfs_accused_of_being_crippled/comment_1_5c5be012e1171ef108f38825d72791b6._comment
new file mode 100644
index 000000000..aa6eb9345
--- /dev/null
+++ b/doc/bugs/encfs_accused_of_being_crippled/comment_1_5c5be012e1171ef108f38825d72791b6._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-06-10T17:22:11Z"
+ content="""
+encfs appears to not allow creation of hard links to files:
+
+[[!format sh \"\"\"
+joey@gnu:~/tmp/other_empty_dir>ln me me2
+ln: failed to create hard link `me2' => `me': Operation not permitted
+\"\"\"]]
+
+According to the documentation, this is a limitation when using External IV Chaining. And only a problem if you choose paranoia mode when setting up encfs.
+
+git-annex uses hard links in a limited number of code paths, most notably `git annex add` uses them when locking down files.
+
+encfs seems like something I'd like to interoperate well with git-annex. So, it seems worthwhile to break out lack of hard links support from the other limitations currently lumped into \"cripped file system\". I've done so.
+
+----
+
+Also made it stop setting direct mode on bare repositories, although that configuration had no effect anyway.
+"""]]
diff --git a/doc/install/OSX.mdwn b/doc/install/OSX.mdwn
index fec346710..97d956d89 100644
--- a/doc/install/OSX.mdwn
+++ b/doc/install/OSX.mdwn
@@ -40,6 +40,7 @@ brew install haskell-platform git ossp-uuid md5sha1sum coreutils libgsasl gnutls
brew link libxml2
cabal update
PATH=$HOME/bin:$PATH
+PATH=$HOME/.cabal/bin:$PATH
cabal install gnuidn
cabal install c2hs git-annex --bindir=$HOME/bin
</pre>