The target folder ("Server") is a cryptomator vault. This happens occasionally, and when it does, a "hidden" file is left behind, as seen in attached screen shot. (long file name, "TKVFDLZCW ..."). I issued the same Duck command again, and the upload succeeded. But the hidden file remains, so I'm guessing that the second successful upload did not "resume" from the first failed upload. This seems common (doesn't resume) and maybe happens because the target folder is a Crytomator vault.
After the second successful upload, I opened Cyberduck, and when I click on the hidden file (to delete it), Cyberduck hangs. You can't click on anything - the window does not respond to any input, nor does the window title bar display "not responding". I fact, it won't even get focus.
When I kill the process (by clicking on the close box of the task bar button), a message box is displayed for a fraction of a second just before the window is closed. It's too quick to read the message.
This occurs reproducibly on Windows 10 running Cyberduck 7.01. When I run Cyberduck 6.9.4 on a Windows 8.1 box, it does not hang.
Let me know if I can provide you with any other information.
Well, when this happens, the hidden file is listed more than once - in the bucket root, and in each folder along the path to the folder into which the file is being uploaded. In the attached screen shot (HiddenFileEntries.jpg), you can see 2 files whose upload failed. The target directory to which the files were being uploaded is Blaise-Backup/Magni/Diff. You can see an entry for each failed upload in each folder: Blaise-Backup (bucket root), Magni, and Diff.
If I delete the entry in the bucket root, the other 2 entries remain in the sub-folders (Magni and Diff). If I click Refresh, these "ghost" entries are removed. But if I click on any of the remaining entries (e.g., right-click, intending to delete), Cyberduck locks up, as described. I have waited as long as 30 minutes to see if it comes back, but it doesn't - I have to kill the Cyberduck process.
I tried to reproduce by interrupting an upload into a Cryptomator vault using Cyberduck CLI with duck --username 3P8EKI02F6OBKT14FITH --upload wasabisys-eu-central-1:/trac-10759/vault/. I can see the duplicate incomplete multipart upload file displayed when browsing with Cyberduck.
It looks like Wasabi S3 does not properly handle the prefix key in API requests like GET /?prefix=SlKGVfW0%2FIK1AMCOk&delimiter=%2F&uploads and returning all pending multipart uploads for a bucket. Review in 2ef561d. I cannot reproduce the hang in the current release.