| Summary: | While copying symlink it copies the target of that symlink. | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kcoreaddons | Reporter: | Eleuth <kteleuth> |
| Component: | general | Assignee: | Michael Pyne <mpyne> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | ad.liu.jin, ben, kdelibs-bugs, kfm-devel, meven29, meven, nate |
| Priority: | NOR | Keywords: | regression |
| Version: | 5.106.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
|
Description
Eleuth
2023-04-29 10:35:38 UTC
I can also reproduce this behavior in version 23.04.0 of Dolphin. This issue doesn't appear to reproduce in a prior release of Dolphin (22.12.03), so it's likely due to a change in 23.04.0 as the reporter suggested. I couldn't find what might be causing the behavior after briefly skimming through Dolphin's commits. I am asking myself how best to fix this. Because for a single symlink that makes sens the user would want the symlink to be "duplicated" at destination. But for a symlink inside a directory being copied (imagine some kind of backup), that could be unexpected for that user and break his workflow. I guess we'd need some input, either when copying a symlink or when copying a folder containing symlink(s). Is there a reason why it shouldn't be like it always has been? I'm working exclusively with relative links and when I make a copy of a folder where normal and symlink files are (linked to files within that directory) I still want exactly what was inside. (In reply to Eleuth from comment #3) > Is there a reason why it shouldn't be like it always has been? I'm working > exclusively with relative links and when I make a copy of a folder where > normal and symlink files are (linked to files within that directory) I still > want exactly what was inside. This seems like a regression. https://invent.kde.org/frameworks/kio/-/commit/00840d05abd875e1901b655ed6af3bc76ef48433 We hadn't unit tests for this, I will be adding one. (In reply to Méven Car from comment #2) > I am asking myself how best to fix this. > > Because for a single symlink that makes sens the user would want the symlink > to be "duplicated" at destination. > But for a symlink inside a directory being copied (imagine some kind of > backup), that could be unexpected for that user and break his workflow. > > I guess we'd need some input, either when copying a symlink or when copying > a folder containing symlink(s). I think by principle of least surprise, we'd better have the same behavior as: (in the order of importance IMHO): 1. `cp' and `cp -r' command. 2. Gnome (Nautilus) 3. Windows (Explorer) IIRC, of the 3, only Windows copies link target. (In reply to Jin Liu from comment #5) > (In reply to Méven Car from comment #2) > > I am asking myself how best to fix this. > > > > Because for a single symlink that makes sens the user would want the symlink > > to be "duplicated" at destination. > > But for a symlink inside a directory being copied (imagine some kind of > > backup), that could be unexpected for that user and break his workflow. > > > > I guess we'd need some input, either when copying a symlink or when copying > > a folder containing symlink(s). > > I think by principle of least surprise, we'd better have the same behavior > as: (in the order of importance IMHO): > 1. `cp' and `cp -r' command. > 2. Gnome (Nautilus) > 3. Windows (Explorer) > IIRC, of the 3, only Windows copies link target. Are you using Wayland btw ? I dug into the code. It is a regression in kcoreaddons 593d3343a30e842a2764faec86347510e8183f91 https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/212 (In reply to Méven from comment #6) > Are you using Wayland btw ? > > I dug into the code. > It is a regression in kcoreaddons 593d3343a30e842a2764faec86347510e8183f91 > https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/212 Yes I'm using wayland. *** This bug has been marked as a duplicate of bug 464225 *** |