From 019a0ec802384edb71fabbee67e318961780d02e Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Thu, 18 Sep 2014 18:27:37 +0000 Subject: [PATCH 1/4] Added a comment --- ...comment_1_12a797cba753168dfde9e6339c00f481._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/forum/Move_unsynced_file_in_direct_mode/comment_1_12a797cba753168dfde9e6339c00f481._comment diff --git a/doc/forum/Move_unsynced_file_in_direct_mode/comment_1_12a797cba753168dfde9e6339c00f481._comment b/doc/forum/Move_unsynced_file_in_direct_mode/comment_1_12a797cba753168dfde9e6339c00f481._comment new file mode 100644 index 0000000000..73a164da26 --- /dev/null +++ b/doc/forum/Move_unsynced_file_in_direct_mode/comment_1_12a797cba753168dfde9e6339c00f481._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="108.236.230.124" + subject="comment 1" + date="2014-09-18T18:27:37Z" + content=""" +Well, you can run `git annex assistant` or `git annex watch` and it will automatically notice the moved file and commit it. I think this is what you were trying to do when you set annex.autocommit to true (which is the default so accomplished nothing). + +But your example does show a bug: `git annex add` should add the dangling symlink to git in direct mode, as it already does in indirect mode. Fixed in [[!commit 44e7d6e1fe6e13091adbd572f66412e3601df3c5]]. +"""]] From ce0f2dd114b24d6457b38bdc9d168d31dab16bfc Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Thu, 18 Sep 2014 18:49:43 +0000 Subject: [PATCH 2/4] Added a comment --- ...comment_1_398c014921f9af957fb5e9a92ed0ef4d._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/bugs/Upload_to_S3_fails_/comment_1_398c014921f9af957fb5e9a92ed0ef4d._comment diff --git a/doc/bugs/Upload_to_S3_fails_/comment_1_398c014921f9af957fb5e9a92ed0ef4d._comment b/doc/bugs/Upload_to_S3_fails_/comment_1_398c014921f9af957fb5e9a92ed0ef4d._comment new file mode 100644 index 0000000000..a18ca1d05a --- /dev/null +++ b/doc/bugs/Upload_to_S3_fails_/comment_1_398c014921f9af957fb5e9a92ed0ef4d._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="108.236.230.124" + subject="comment 1" + date="2014-09-18T18:49:43Z" + content=""" +This is using the old hS3 library. So, each chunk is sent using a new http connection. It seems that the connection must be being closed by S3 part way through the upload of a chunk. + +It may be that the new aws library somehow avoids this problem. So, a git-annex built with the `s3-aws` branch merged in may help with this bug. OTOH, that new branch makes a single http connection be reused for all the chunks in a file, so it might also make things worse. +"""]] From 74ad8ebb0cd4c34f6b8f84d9a0bfde6b23268baf Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Thu, 18 Sep 2014 18:52:17 +0000 Subject: [PATCH 3/4] Added a comment --- ...comment_2_f33ce058c9460cf7d151e739bff0440a._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/bugs/Upload_to_S3_fails_/comment_2_f33ce058c9460cf7d151e739bff0440a._comment diff --git a/doc/bugs/Upload_to_S3_fails_/comment_2_f33ce058c9460cf7d151e739bff0440a._comment b/doc/bugs/Upload_to_S3_fails_/comment_2_f33ce058c9460cf7d151e739bff0440a._comment new file mode 100644 index 0000000000..dcf719bba7 --- /dev/null +++ b/doc/bugs/Upload_to_S3_fails_/comment_2_f33ce058c9460cf7d151e739bff0440a._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="108.236.230.124" + subject="comment 2" + date="2014-09-18T18:52:17Z" + content=""" +If you're using the new chunking system, git-annex should support resuming the upload to S3. Next time you try to send the file, it should find the chunks that were successfully sent, and resume at the chunk where it failed. + +Supporting this even for encrypted uploads was a major benefit of the new chunking system, so I hope it works...? +"""]] From 2ebcc69d638c717cb02ddb84d8bf25895c33f839 Mon Sep 17 00:00:00 2001 From: xn Date: Thu, 18 Sep 2014 19:03:30 +0000 Subject: [PATCH 4/4] Added a comment --- ..._f3aec24668c35780a033f2b035df10ee._comment | 20 +++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 doc/forum/Move_unsynced_file_in_direct_mode/comment_2_f3aec24668c35780a033f2b035df10ee._comment diff --git a/doc/forum/Move_unsynced_file_in_direct_mode/comment_2_f3aec24668c35780a033f2b035df10ee._comment b/doc/forum/Move_unsynced_file_in_direct_mode/comment_2_f3aec24668c35780a033f2b035df10ee._comment new file mode 100644 index 0000000000..971e70cdca --- /dev/null +++ b/doc/forum/Move_unsynced_file_in_direct_mode/comment_2_f3aec24668c35780a033f2b035df10ee._comment @@ -0,0 +1,20 @@ +[[!comment format=mdwn + username="xn" + ip="71.59.214.243" + subject="comment 2" + date="2014-09-18T19:03:30Z" + content=""" +Thanks for tracking down that bug and for clearing up my confusion about `annex.autocommit`, Joey. + +I didn't realize `annex.autocommit=true` is only used by `git annex assistant` and `git annex watch`. I thought that running `git annex sync` with `annex.autocommit=true` would also commit the change. + +A few small changes to `git-annex(1)` could clarify: + + sync [remote ...] + ... + The sync process involves first committing all local *staged* changes... + + annex.autocommit + Set to false to prevent git-annex assistant and *git-annex watch* from automatically committing changes to files in the repository. + +"""]]