Cyberduck Mountain Duck CLI

#4462 closed defect (fixed)

Default transfer action should be resume for automatically retried previously failed transfers

Reported by: Owned by: dkocher
Priority: normal Milestone: 3.6
Component: core Version: 3.4.2
Severity: normal Keywords: multiple files copy bug
Cc: Architecture:
Platform: Mac OS X 10.5


This just happened with two large files (about 7.9 GB and 6.7 GB) while logged onto an ftp site with a password. I logged onto the server and selected both "File1" and "File2" which were in a folder called "FILES." I selected the two files by opening the folder, and by shift-clicking to highlight both. Then I dragged both files to a location on one of my hard drives.

Cyberduck reported that it would take about 15 hours and the total of the transfer was 14.7 GB. However, after about 8 hours (at the 7.9 GB mark) it did this instead:

1) A warning dialog came up asking if I wanted to OVERWRITE "File1" (which was already downloaded after 8 hours). The original file and the file on the server had the exact same modification date and size. So, I assumed this was a bug. So, to avoid going through another 8 hours of download time, I clicked CANCEL so it would NOT overwrite the already downloaded file.

2) Cyberduck then cancelled the operation and the progress bar reported "Transfer incomplete" with "7.9 GB of 14.7 GB." The first file of the two files I wanted to download appears to have been downloaded OK.

(So I went ahead and began the download of "File2" separately.)

Thus, there appears to be a bug. If you SHIFT-CLICK to select multiple files to download, only the FIRST file gets downloaded. Then Cyberduck thinks that the second file is the first file and thinks I want to overwrite the first file. If I did, it probably would have erased the first file and I would have had to download it twice.

Unfortunately, I neglected to take screenshots, and when I opened the "Log Drawer," there was no log there. However, I hope the description is accurate and you can reproduce.

Many thanks!

  • Franklin

Change History (2)

comment:1 Changed on Jul 27, 2010 at 4:40:31 PM by dkocher

  • Milestone set to 3.6
  • Resolution set to fixed
  • Status changed from new to closed

The issue here is that the transfer was interrupted after the download of the first file has completed possibly because of an underlying networking error. The transfer was restarted automatically according to the settings in Connection Preferences. By default, the user was asked what to with the already existing file from the first attempt. We have now changed this in r6418 to resume the transfer upon retry.

comment:2 Changed on Jul 27, 2010 at 4:41:20 PM by dkocher

  • Summary changed from Copying two files bug to Default transfer action should be resume for automatically retried previously failed transfers
Note: See TracTickets for help on using tickets.