Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Folder contents merged if named the same #936

Closed
cyberduck opened this issue Oct 20, 2006 · 2 comments
Closed

Folder contents merged if named the same #936

cyberduck opened this issue Oct 20, 2006 · 2 comments

Comments

@cyberduck
Copy link
Collaborator

8fbae90 created the issue

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),
      1. 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,
      1. or if they'd instead prefer to "Use a similar name" for the new folder,
  • 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.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

As of 6633ca8. files to be overwritten localy are moved to the Trash.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

See also #5117. We now have an action Rename existing for both uploads and downloads which renames an existing folder before the transfer starts. In 2ee6742.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants