Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multipart uploads unable to resume properly #8783

Closed
cyberduck opened this issue Apr 30, 2015 · 15 comments
Closed

Multipart uploads unable to resume properly #8783

cyberduck opened this issue Apr 30, 2015 · 15 comments
Assignees
Labels
bug fixed high priority s3 AWS S3 Protocol Implementation
Milestone

Comments

@cyberduck
Copy link
Collaborator

9ba9865 created the issue

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. :-)


Attachments

@cyberduck
Copy link
Collaborator Author

@dkocher commented

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.

@cyberduck
Copy link
Collaborator Author

9ba9865 commented

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.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

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.

@cyberduck
Copy link
Collaborator Author

9ba9865 commented

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.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

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

@cyberduck
Copy link
Collaborator Author

9ba9865 commented

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!

@cyberduck
Copy link
Collaborator Author

9ba9865 commented

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

@cyberduck
Copy link
Collaborator Author

@dkocher commented

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

@cyberduck
Copy link
Collaborator Author

9ba9865 commented

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).

@cyberduck
Copy link
Collaborator Author

@dkocher commented

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

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.

@cyberduck
Copy link
Collaborator Author

9ba9865 commented

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!

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:15 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.

@cyberduck
Copy link
Collaborator Author

9ba9865 commented

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.

@cyberduck
Copy link
Collaborator Author

9ba9865 commented

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. :-)

@cyberduck
Copy link
Collaborator Author

@dkocher commented

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

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug fixed high priority s3 AWS S3 Protocol Implementation
Projects
None yet
Development

No branches or pull requests

2 participants