I regularly moving or copying files that some of them are symlinks. So far I didn't have any problems with that but the last update changed something and now instead of copying/moving symlink it copies/moves the original file that is that symlink's target. It doesn't happen when the files are in a folder, only when copying/moving files directly STEPS TO REPRODUCE 1. Ctrl+c the symlink file. 2. Select destination folder. 3. Ctrl+v OBSERVED RESULT Different file shows up in destination folder. EXPECTED RESULT It should be symlink, if it's relative link it should be broken but nevertheless it should be exactly what I've copied.X SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9
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 ***