[Cyberduck-trac] [Cyberduck] #936: Folder contents merged if named the same

Cyberduck trac at trac.cyberduck.ch
Fri Oct 20 11:11:11 CEST 2006

#936: Folder contents merged if named the same
 Reporter:  jamescat  |       Owner:  dkocher                                       
     Type:  defect    |      Status:  new                                           
 Priority:  high      |   Milestone:  2.6.5                                         
Component:  core      |     Version:  2.6.2                                         
 Severity:  major     |    Keywords:  similar folder merge resume transfer overwrite
 When downloading two similarly named folder items from different hosts,
 such as the "images" folder from two website hosting providers for
 instance, the contents of the folders end up getting merged into one
 "images" folder in your download location. ''- If there are similarly
 named files '''within''' the folders, you are asked what to do (if that's
 your preference), but you are never asked about the folders themselves.''

 Expected behavior by default is probably that a new folder be created with
 a trailing number, like the Finder does for Screenshots, rather than that
 the contents are merged like the ditto command line utility would do.

 However, beyond that, the desired behavior, based on the "Duplicate files"
 preference, would probably be to:
  * A) if "Ask me what to do" is selected, then ask just as if it were a
 filename that already existed, '''but beforehand''' to also check to see
 if the local contents have "extra" files that are missing on the source
 server - indicating that it isn't the a good match for a resume operation
 ... and if so, notify the user ''before making their choice'' that the
 existing local folder does not appear to match the contents from the
 current remote site, and ask them:
    * 1) if they would like to "Overwrite existing file" by moving the
 existing folder to the Trash and starting all over - (moving to the Trash
 instead of deleting wholesale, so that the contents can be recovered if
 they realize it was a mistake after all),
    * 2) or if they really want to '''"Merge"''' the existing folder with
 the new files by "Resuming the transfer" - '''''even though the contents
 don't look like they match, and there will be extra files that don't match
 the existing server layout''''',
    * 3) or if they'd instead prefer to "Use a similar name" for the new
  * B) if "Overwrite existing file", then move the existing directory to
 the User's Trash folder (so it can still be recovered if they realize they
 lost it, and want it back) and start the transfer from scratch, by
 recreating the empty directory,
  * C) if "Try to resume transfer", then behave just like the test in (A)
 where you check that all the files in the local copy have corresponding
 items in the remote source folder, and ask them the question about
 "Merging" if the structures don't match,
  * D) if "Use similar name", then do just like usual for that option

 The differentiation between "Merging" and "Resuming" could, I suppose, be
 considered a separate ''enhancement'' (with lower priority/severity)
 instead of part of the solution to the ''defect'', and merely have the
 preference followed for folders exactly as it is for files. - ''But in my
 mind,'' it should be part of the solution, rather than a separate issue,
 since it fixes the behavior to be "safer" for the user.

 Also, I would presume that something similar may happen when uploading as
 well, but I don't currently have a server handy where I feel comfortable
 messing around with the files the way I need to for testing that
 supposition. ... I'll try to post a comment soon if I can manage to
 confirm or refute that the behavior happens for uploads too.

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

More information about the Cyberduck-trac mailing list