Cyberduck Mountain Duck CLI

#8783 closed defect (fixed)

Multipart uploads unable to resume properly

Reported by: dag02005 Owned by: dkocher
Priority: high Milestone: 4.7.1
Component: s3 Version: 4.7
Severity: normal Keywords:
Cc: Architecture:
Platform:

Description

Hello,

We previously logged a ticket (#8697) where a 443 error was stopping the upload on our system with Mac OS X Yosemite. Switching to the latest Nightly Build fixed that problem, but now we're getting another version.

Sometimes, during an upload, we get an "Upload Failed" error message. This by itself isn't so bad...when it happens on our other systems, we just click Try Again, Resume, and it continues uploading form where it left off.

However, on our Yosemite system (Cyberduck 4.7 build 17342) it starts over from the beginning, and then can't make it to the end without glitching out. I've attached a log.

Thank you for your help, and please let us know what we can do to get Cyberduck working on this system. We really, really don't want to use BucketExplorer. :-)

Change History (25)

comment:1 Changed on May 1, 2015 at 6:03:35 AM by dkocher

  • Component changed from core to s3
  • Owner set to dkocher
  • Summary changed from 443 Error, Uploads Unable to Resume Properly to 443 Error, Multipart Uploads Unable to Resume Properly

comment:2 Changed on May 1, 2015 at 8:11:31 AM by dkocher

Can you post the error message displayed. If you get a 403 error you are possibly missing permission to list multipart uploads. Refer to Multipart Upload API and Permissions.

comment:3 Changed on May 1, 2015 at 8:19:55 AM by dkocher

  • Summary changed from 443 Error, Multipart Uploads Unable to Resume Properly to Multipart Uploads Unable to Resume Properly

comment:4 Changed on May 2, 2015 at 6:47:44 AM by dkocher

  • Milestone set to 4.8
  • Resolution set to worksforme
  • Status changed from new to closed

comment:5 Changed on May 4, 2015 at 10:10:52 PM by dag02005

Can you please reopen this ticket? It wasn't a 403 error but a 443 error. I doubt it has to do with our S3 settings, because uploading to this same S3 server (using older versions of Cyberduck, in fact) works on every other device in our office. Many apologies for the delayed reply, and I'll be much more present this week for any testing you need done to get this fixed fast.

comment:6 Changed on May 5, 2015 at 8:29:43 AM by dkocher

  • Resolution worksforme deleted
  • Status changed from closed to reopened

There is no HTTP Status Code 443. Please post the transcript from the log drawer of the Transfers window. Choose ⌘-L on Mac or right-click the toolbar from the Transfers window and choose Log on Windows.

Changed on May 6, 2015 at 9:38:18 PM by dag02005

comment:7 Changed on May 6, 2015 at 9:39:55 PM by dag02005

Thank you for the clarification about 443. I've attached a screenshot so you can see what we see, plus a full log detailing the attempted upload, the error, the attempt to try again, and starting over from the beginning.

comment:8 Changed on May 13, 2015 at 1:46:42 PM by dkocher

Can you please update to the latest stable version (r17432) and let me know if the problem persists.

comment:9 Changed on May 14, 2015 at 8:47:29 PM by dag02005

Sure thing. Where do I download build 17432? There's no zip file for that version in the list of Nightly Builds, and the files at https://trac.cyberduck.io/changeset/17432 aren't downloading. Thank you!

comment:10 Changed on May 14, 2015 at 8:49:15 PM by dag02005

I can confirm this issue happens in the version (4.7, 17427) we bought off the app store.

comment:11 Changed on May 14, 2015 at 9:01:17 PM by dkocher

  • Status changed from reopened to new

comment:12 Changed on May 15, 2015 at 10:48:21 AM by dkocher

Can you give us more detail what combination of OS X and Cyberduck is working as you mentioned in the ticket description.

comment:13 Changed on May 15, 2015 at 6:39:14 PM by dag02005

Yes indeed. Cyberduck is working fine on our old machine which runs Mac OS X 10.9.4. The Cyberduck version is 4.4.3 (14140).

comment:14 Changed on May 19, 2015 at 10:37:23 AM by dkocher

Can you again try if disabling connection reuse will resolve the problem using the hidden configuration option http.connections.reuse available since r17224.

Enter

defaults write ~/Library/Containers/ch.sudo.cyberduck/Data/Library/Preferences/ch.sudo.cyberduck.plist  http.connections.reuse false

in a Terminal.app window when and relaunch Cyberduck.app installed in /Applications from the Mac App Store.

comment:15 follow-up: Changed on May 20, 2015 at 5:15:04 PM by dag02005

So far, so good! It uploaded a 40GB file with no errors. I'll continue testing, and write back if the problem recurs.

Thank you!

comment:16 in reply to: ↑ 15 Changed on May 20, 2015 at 5:26:57 PM by dkocher

Replying to dag02005:

So far, so good! It uploaded a 40GB file with no errors. I'll continue testing, and write back if the problem recurs.

Thank you!

Please let me know in any case so we can change the default if it obviously makes trouble in some network environments.

comment:17 Changed on May 21, 2015 at 12:26:29 AM by dag02005

Sure thing. It looks like I spoke to soon. The latest upload hit an error, and when I hit Resume, it started over from the beginning. I'm attaching the log. Please let us know if there's anything you need.

comment:18 Changed on Jun 8, 2015 at 9:38:18 PM by dag02005

We fixed this problem this old-fashioned way: we reverted to an older version (4.4.3, build 14140) on the new MacPro, and now everything works fine. When an upload is interrupted, it gives a different error message, but successfully resumes when you tell it to.

From a practical angle, everything is fine for us now, but I wanted to let you know in case it provides a clue for later versions. It would be great to be able to get the latest update and still enjoy the same functionality. :-)

comment:19 Changed on Jun 29, 2015 at 9:13:53 AM by dkocher

  • Summary changed from Multipart Uploads Unable to Resume Properly to Multipart uploads unable to resume properly

comment:20 Changed on Jun 29, 2015 at 11:19:54 AM by dkocher

  • Priority changed from normal to high

comment:21 Changed on Jun 30, 2015 at 8:04:38 AM by dkocher

  • Milestone changed from 4.8 to 4.7.1
  • Resolution set to fixed
  • Status changed from new to closed

Possible fix in r17874 where there are multiple uploads for the same key not yet completed. We are now choosing the latest when appending.

Note: See TracTickets for help on using tickets.
swiss made software