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

Synchronize subfolders erronously looks in similarly named symbolic links #6860

cyberduck opened this issue Sep 16, 2012 · 1 comment


Copy link

@cyberduck cyberduck commented Sep 16, 2012

Haraldb42 created the issue

When the synchronize function looks in subfolders, it erronously includes local files that reside in a completely different folder that simply happens to have the same name and being the target of a symbolic link. An example makes it easier to understand:

  1. Let's call the folders to be synchronized for 'MainFolder', same name in the local and remote domains.
  2. Both the local and remote 'MainFolder' have a subfolder called 'pics'.
  3. Both the local and remote 'MainFolder' also have a symbolic link named 'picsCommon' that points to a folder named 'pics' that resides above 'MainFolder'.
  4. When Synchronize compares and lists files in the the subfolder 'MainFolder/pics', it will ALSO include all files in the local 'picsCommon'!! That's very wrong! Thus, it lists the union of all files in 'MainFolder/pics' plus the files in the folder 'pics' that reside above 'MainFolder', as if they were all in 'MainFolder/pics'!

If I do a synchronize ONLY of 'MainFolder/pics', then it behaves as it should because that does not contain any subfolders.

Copy link
Collaborator Author

@cyberduck cyberduck commented Nov 26, 2012

@dkocher commented

Should be fixed with d09699a and later.


@cyberduck cyberduck closed this Nov 26, 2012
@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.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants