From 6e18131a499bda40378f60693169b3032115ca06 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawkexhIpGcYa22aPQtLm-StpHiF-MHYPh5w" Date: Mon, 10 Jun 2013 17:21:26 +0000 Subject: Add further workaround instructions --- doc/bugs/Glacier_remote_uploads_duplicates.mdwn | 2 ++ 1 file changed, 2 insertions(+) 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. -- cgit v1.2.3 From 092b29409cc2f04e2bff4f72a376091b206d6776 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Mon, 10 Jun 2013 17:22:11 +0000 Subject: Added a comment --- ...ent_1_5c5be012e1171ef108f38825d72791b6._comment | 23 ++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 doc/bugs/encfs_accused_of_being_crippled/comment_1_5c5be012e1171ef108f38825d72791b6._comment 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. +"""]] -- cgit v1.2.3 From cadf340249e8760f826861ae2e50473534788926 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawkexhIpGcYa22aPQtLm-StpHiF-MHYPh5w" Date: Mon, 10 Jun 2013 17:24:34 +0000 Subject: Added a comment --- .../comment_6_feea067d6856af2840604782b29af86a._comment | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 doc/bugs/Glacier_remote_uploads_duplicates/comment_6_feea067d6856af2840604782b29af86a._comment 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. +"""]] -- cgit v1.2.3 From 9eb78d7e01f8d8eed059534ef686fecf8b1022ea Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawl9J51AO9t75xN5k0sJgg8taUo4y0a4hpQ" Date: Mon, 10 Jun 2013 19:00:33 +0000 Subject: Added cabal bin path for brew --- doc/install/OSX.mdwn | 1 + 1 file changed, 1 insertion(+) 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 -- cgit v1.2.3 From aefe9bb78552950e6b1ce4222bf071e545d001de Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Mon, 10 Jun 2013 20:30:28 +0000 Subject: Added a comment --- ...comment_1_2fe6d735bc075275a6b8890fac48ee58._comment | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 doc/bugs/Specifying_a_filename_starting_with___34__-c__34___instead_applies_it_to_all_files/comment_1_2fe6d735bc075275a6b8890fac48ee58._comment 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! +"""]] -- cgit v1.2.3