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:
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.
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.
The text was updated successfully, but these errors were encountered:
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 7d80a18 to resume the transfer upon retry.