Cyberduck Mountain Duck CLI

#10759 closed defect (worksforme)

Hangs when click on a unfinished upload file left after failure to complete upload into encrypted folder

Reported by: MarkBlaise Owned by: dkocher
Priority: normal Milestone: 7.4
Component: cryptomator Version: 7.0.1
Severity: normal Keywords:
Cc: Architecture: Intel
Platform: Windows 10

Description

A file upload via Duck CLI to a Cryptomator vault failed. The last 8 lines of Duck output follow:

[▮▮▮▮▮▮▮▮▮▮▮▮▮                 ] 350.0 MiB (367,001,600 bytes) of 799.0 MiB (43%, 7.9 MB/sec, 60 seconds remaining)
[▮▮▮▮▮▮▮▮▮▮▮▮▮                 ] 340.0 MiB (356,515,840 bytes) of 799.0 MiB (42%, 7.6 MB/sec, 64 seconds remaining)
Transfer incomplete…
Upload TKVFDLZCWLMMFWR4QANKZW6PIXSYIAOTLGEKRGVB5H4RZJJFXUB4BFVCJYL2XR4VMJ4K3LGSH4MA==== failed. We encountered an internal error.  Please retry the operation again later. Please contact your web hosting service provider for assistance.


[▮▮▮▮▮▮▮▮▮▮                    ] 280.0 MiB of 799.0 MiB
[▮▮▮▮▮▮▮▮▮▮                    ] 270.0 MiB of 799

Here is the duck command issued:

duck  -P --existing resume --parallel 32     --upload wasabisys://T5ZHIOV9VGMNBAKU1HQ4@Blaise-Backup/Server/ \\Odin\Backup-Staging\Server\20190710-031246-D_B2D000217.bkf

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.

Attachments (2)

Hang-v7.01.jpg (244.0 KB) - added by MarkBlaise on Jul 10, 2019 at 1:45:17 PM.
screen shot of Cyberduck showing hidden file after upload failure
HiddenFileEntries.jpg (191.1 KB) - added by MarkBlaise on Aug 21, 2019 at 3:54:47 PM.
screen shot of Cyberduck showing multiple entries of hidden files

Download all attachments as: .zip

Change History (10)

Changed on Jul 10, 2019 at 1:45:17 PM by MarkBlaise

screen shot of Cyberduck showing hidden file after upload failure

comment:1 Changed on Jul 17, 2019 at 3:05:15 PM by dkocher

  • Milestone set to 7.1
  • Owner set to dkocher
  • Status changed from new to assigned
  • Summary changed from Cyberduck hangs when click on a "hidden" file left after failure to complete upload into cryptomator folder to Hangs when click on a unfinished upload file left after failure to complete upload into encrypted folder

comment:2 Changed on Aug 21, 2019 at 3:27:39 PM by dkocher

Thanks for your detailed bug report. I tried to reproduce this issue with selecting an unfinished upload to Wasabi S3 into a Cryptomator vault but cannot reproduce the crash by selecting the file.

comment:3 Changed on Aug 21, 2019 at 3:28:07 PM by dkocher

I can however reproduce a crash when opening the Info panel.

Changed on Aug 21, 2019 at 3:54:47 PM by MarkBlaise

screen shot of Cyberduck showing multiple entries of hidden files

comment:4 Changed on Aug 21, 2019 at 3:55:36 PM by MarkBlaise

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 hope that helps ...

comment:5 Changed on Sep 11, 2019 at 2:10:39 PM by dkocher

  • Milestone changed from 7.1 to 8.0

Ticket retargeted after milestone closed

comment:6 Changed on May 24, 2020 at 6:43:26 PM by dkocher

Sorry for not following up on this earlier. Can you still reproduce this in the current release?

comment:7 Changed on May 24, 2020 at 6:49:08 PM by dkocher

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.

comment:8 Changed on May 25, 2020 at 2:47:30 PM by dkocher

  • Milestone changed from 8.0 to 7.4
  • Resolution set to worksforme
  • Status changed from assigned to closed

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 r49278. I cannot reproduce the hang in the current release.

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