diff options
author | 2015-07-16 15:01:55 -0400 | |
---|---|---|
committer | 2015-07-16 15:01:55 -0400 | |
commit | a63e44eef44d7a0c424b8ddf0a7d0a8832a313f6 (patch) | |
tree | 7230de298d43bdaac2908c2d0434a55e3ef47bf3 /doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking | |
parent | 1396113ccbb6be895b1deb7c7eec228323e47078 (diff) |
move forum bug report to bugs, and close
Diffstat (limited to 'doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking')
4 files changed, 55 insertions, 0 deletions
diff --git a/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_1_f6b1991e259bf4b3d2c85a08f465aa4a._comment b/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_1_f6b1991e259bf4b3d2c85a08f465aa4a._comment new file mode 100644 index 000000000..79f0fe873 --- /dev/null +++ b/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_1_f6b1991e259bf4b3d2c85a08f465aa4a._comment @@ -0,0 +1,7 @@ +[[!comment format=mdwn + username="anarcat" + subject="comment 1" + date="2015-06-24T00:31:43Z" + content=""" +did a single chunk get transfered correctly? i believe git-annex can only resume at the chunk granularity... that is what it is for, no? --[[anarcat]] +"""]] diff --git a/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_2_db57d14b983a957c454968477d9de634._comment b/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_2_db57d14b983a957c454968477d9de634._comment new file mode 100644 index 000000000..df12abc03 --- /dev/null +++ b/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_2_db57d14b983a957c454968477d9de634._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="digiuser" + subject="yes" + date="2015-06-24T00:49:22Z" + content=""" +Yes, a single chunk did get transferred correctly. + +Actually, many times I've run this experiment, many chunks did get transferred correctly. I've even verified that they are in S3, but git-annex is trying to re-upload them. + +(I haven't checked their contents in S3 but the filenames are there and the sizes are there) +"""]] diff --git a/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_3_85989f505931ec695d7f3de74db0f5a1._comment b/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_3_85989f505931ec695d7f3de74db0f5a1._comment new file mode 100644 index 000000000..aac24a023 --- /dev/null +++ b/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_3_85989f505931ec695d7f3de74db0f5a1._comment @@ -0,0 +1,7 @@ +[[!comment format=mdwn + username="digiuser" + subject="any updates?" + date="2015-06-29T03:05:53Z" + content=""" +Sorry to post again here but I was wondering if this message got lost. Anyone have a solution here? Thanks! +"""]] diff --git a/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_4_bd631d470ee0365a11483c9a2e563b32._comment b/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_4_bd631d470ee0365a11483c9a2e563b32._comment new file mode 100644 index 000000000..ecac7917c --- /dev/null +++ b/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_4_bd631d470ee0365a11483c9a2e563b32._comment @@ -0,0 +1,30 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 4""" + date="2015-07-16T17:57:44Z" + content=""" +This should have been filed as a bug report... I will move the thread to +bugs after posting this comment. + +In your obfuscated log, it tries to HEAD GPGHMACSHA1--1111111111 +and when that fails, it PUTs GPGHMACSHA1--2222222222. From this, we can +deduce that GPGHMACSHA1--1111111111 is not the first chunk, but is the full +non-chunked file, and GPGHMACSHA1--2222222222 is actually the first chunk. + +For testing, I modifed the S3 remote to make file uploads succeed, but then +report to git-annex that they failed. So, git annex copy uploads the 1st +chunk and then fails, same as it was interrupted there. Repeating the copy, +I see the same thing; it HEADs the full key, does not HEAD the first chunk, +and so doesn't notice it was uploaded before, and so re-uploads the first +chunk. + +The HEAD of the full key is just done for backwards compatability reasons. +The problem is that it's not checking if the current chunk it's gonna +upload is present in the remote. But, there is code in seekResume that +is supposed to do that very check: `tryNonAsync (checker k)` + +Aha, the problem seems to be in the checkpresent action that's passed to +that. Looks like it's passing in a dummy checkpresent action. + +I've fixed this in git, and now it resumes properly in my test case. +"""]] |