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

dcp and dsync: handle when destination link exists with different target #412

Closed
daltonbohning opened this issue Oct 20, 2020 · 2 comments · Fixed by #618
Closed

dcp and dsync: handle when destination link exists with different target #412

daltonbohning opened this issue Oct 20, 2020 · 2 comments · Fixed by #618

Comments

@daltonbohning
Copy link
Collaborator

daltonbohning commented Oct 20, 2020

Example:
If we have these links:

link1 -> file1
link2 -> file2

And run dsync like this:

dsync link1 dst
dsync link2 dst

Then we get:

dst -> file1

But dst -> file2 would be expected.
Similarly, this happens when copying directories that contain links.
This happens with both dcp and dsync.

@daltonbohning daltonbohning changed the title dsync: handle when destination link exists with different target dcp and dsync: handle when destination link exists with different target Oct 22, 2020
@daltonbohning
Copy link
Collaborator Author

It doesn't seem there is a system call to update a link target. It seems the only way to update the target is to delete the destination before creating the symlink.
That's what cp seems to do:

strace cp --no-dereference some_link existing_link
...
stat("existing_link"...
lstat("some_link"...
lstat("existing_link"...
unlink("existing_link"...
...
symlink(... "existing_link"...

@jbd
Copy link

jbd commented Feb 3, 2024

Hello,

Just updating the issue to say that I've been hit by this behavior. It would be nice to have it corrected of course ;)

In the meantime as a workaround, I'm using dfind --type l followed by drm before running dsync again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants