[Cyberduck-trac] [Cyberduck] #1513: SCP transfer - attempts to resume, even though it technically can't - results in file with duplicate portions of resumed data

[Cyberduck]

#1513: SCP transfer - attempts to resume, even though it technically can't -
results in file with duplicate portions of resumed data
-------------------------------+--------------------------------------------
 Reporter:  ryebrye at gmail.com  |       Owner:  dkocher   
     Type:  defect             |      Status:  new       
 Priority:  normal             |   Milestone:            
Component:  sftp               |     Version:  2.8.2     
 Severity:  normal             |    Keywords:  scp resume
-------------------------------+--------------------------------------------
 Transferring 3 large files with "scp" selected as the SFTP transfer
 method, I stopped each transfer around 30 megs so I could change my
 network connection to a more reliable wired connection.

 When the files go to the point they were supposed to be done, the transfer
 continued past the maximum file size, and the ETA time started going
 negative.

 Opening the files in a binary file editor, it was clear that what happened
 was instead of "resuming" the file, the entire file was appended to the
 existing file that was downloaded.

 I don't believe SCP is capable of doing resumes, so I was surprised when
 CyberDuck gave me that option - and I thought "hey, cool, CyberDuck has
 some magic way of resuming scp transfers... might as well try it"

 With a hex editor, it was trivial to remove the portion that was
 duplicated (search for the first 1024 or 2048 bits which in the split
 bzip2 file are pretty much guaranteed to be unique and find the offset
 they are repeated at - then delete everything prior to that offset and
 save it...)

 When using the SCP transfer method, it should either warn you that you
 wont be able to resume (put this in the preferences) - and when you try to
 download an existing file, it should not present you with the option to
 resume it.

 If SOME scp transfers are capable of being resumed - you could implement a
 method to check it - where it will download the first few Kb into a buffer
 and you could compare that with the first few Kb of the portion to resume
 to check that it is, in fact, resuming - then continue on - or delete the
 existing portion and redownload the whole file.

 I'm not an expert on the details of SCP, so I don't know if it is ever
 capable of being resumed or not.

-- 
Ticket URL: <http://trac.cyberduck.ch/ticket/1513>
Cyberduck <http://cyberduck.ch>
FTP and SFTP Browser for Mac OS X.