Bug 464225 - copy/move symbolic link moves link destination instead
Summary: copy/move symbolic link moves link destination instead
Status: RESOLVED FIXED
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.102.0
Platform: Neon Linux
: VHI critical
Target Milestone: ---
Assignee: KIO Bugs
URL:
Keywords:
: 469134 472180 472972 (view as bug list)
Depends on:
Blocks:
 
Reported: 2023-01-13 06:18 UTC by S. Christian Collins
Modified: 2023-08-07 06:49 UTC (History)
20 users (show)

See Also:
Latest Commit: https://invent.kde.org/frameworks/kcoreaddons/-/commit/2ec1a017b4cd0c56318b38ccd92b523ad21a1a08
Version Fixed In: 5.109

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description S. Christian Collins 2023-01-13 06:18:11 UTC 
If you copy a symbolic link in Dolphin, it pastes the link target instead of making a copy of the symlink. If you move a symbolic link, it moves the link target instead while breaking the symbolic link you tried to move. This is a regression from earlier versions of Dolphin (not sure when was the last good version) and affects the current development version 23.03.70.

STEPS TO REPRODUCE
1. Create a file (I just made a basic text file called "test.txt")
2. Create two folders: "folder1" and "folder2"
3. Create a symbolic link to "test.txt" in folder1.
4. Move the symbolic link from folder1 to folder2.

OBSERVED RESULT
The "test.txt" file created in step 1 is moved to "folder2" while the symbolic link created in step 3 remains in "folder1". This link, of course, is now broken, since it still points to the original location of "test.txt".

EXPECTED RESULT
The symbolic link should have been moved from "folder1" to "folder2" and the actual "test.txt" file should never have been moved.

If you try copying the symbolic link instead of moving it, you will end up with a copy of the link target (the actual "test.txt") in folder2 instead of a copy of the symbolic link.

SOFTWARE/OS VERSIONS
OS: KDE neon Unstable Edition
KDE Plasma Version: 5.26.80
KDE Frameworks Version: 5.102.0
Qt Version: 5.15.8
Comment 1 Jérôme Borme 2023-06-10 23:08:01 UTC 
This bug can cause data loss so I would say it is quite important. For me it's a blocker for the v23 series of dolphin (v22.12 is good). The scenario for data loss (happened to me, fortunately I have backups) is using dolphin to move a symbolic link to another directory, then deciding to delete the link. In this bug, dolphin moves the original file rather than the link, so the user ends up deleting the original file and is left with the broken link. This bug makes dolphin unusable for file management tasks involving symbolic links.

Another way to reproduce the bug
In a directory, do: touch t1; ln -s t1 t2
in dolphin, select t2 (the link), press ctrl-X and just see that it's actually t1 (the original) that is visually greyed as the file that will be moved.

I attempted to bisect between v22.12.3 and 23.04.2 but got a bad merge base. (I am not very proficient with these, I just understand it cannot pinpoint the commit precisely.)
The merge base c193c45a30e96e77a6b733eb6c5774ec8986911c is bad.
This means the bug has been fixed between c193c45a30e96e77a6b733eb6c5774ec8986911c and [6db97c1ee3818527828e941844570b7eb76600d5]
Comment 2 Dick Tracey 2023-06-24 19:46:51 UTC 
I also lost data because of this bug.

Copying a symbolic link should copy the symbolic link itself, and should not copy or move the destination.

This is a very serious bug and its priority should be increased.
Comment 3 Dick Tracey 2023-06-24 19:49:42 UTC 
> This means the bug has been fixed between
> c193c45a30e96e77a6b733eb6c5774ec8986911c and
> [6db97c1ee3818527828e941844570b7eb76600d5]

Do you mean the bug has been "introduced" instead of "fixed"? Because I'm using Dolphin 23.04.2, and the bug still exists.
Comment 4 Dick Tracey 2023-06-24 19:57:14 UTC 
I just found out that the same bug also exists in Konqueror 23.04.2 as well, so it looks like this is a bug in a common I/O code (KIO?)
Comment 5 Dick Tracey 2023-06-24 20:49:44 UTC 
I reproduced the bug on an ext4 filesystem (as well as btrfs), so it's not specific to CoW filesystems. Behavior is the same.

Moving a symlink: moves the target of the link to destination (so the original symlink becomes a broken symlink)
Copying a symlink: copies the target of the link to destination
Comment 6 Michael 2023-06-25 07:12:54 UTC 
I can confirm this problem exists on a f2fs filesystem on this setup:

Operating System: KDE neon 5.27
KDE Plasma Version: 5.27.6
KDE Frameworks Version: 5.107.0
Qt Version: 5.15.10
Comment 7 Nate Graham 2023-06-26 19:17:44 UTC 
Raising priority and severity due to data loss impact. On first glance, some of the commits in https://invent.kde.org/frameworks/kio/-/merge_requests/511 and https://invent.kde.org/frameworks/kio/-/merge_requests/592 look like they could have caused this.
Comment 8 Nate Graham 2023-06-27 18:00:17 UTC 
*** Bug 469134 has been marked as a duplicate of this bug. ***
Comment 9 Nate Graham 2023-06-27 18:00:29 UTC 
Migrating comment from https://bugs.kde.org/show_bug.cgi?id=469134#c6 since that's now marked as a duplicate of this one:

Appears to be a regression from https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/212/
Comment 10 Bug Janitor Service 2023-06-29 10:43:53 UTC 
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/348
Comment 11 Harald Sitter 2023-07-04 14:27:51 UTC 
Git commit 14e954248e365098e4b98cfd7c76e5ea1defb8a7 by Harald Sitter.
Committed on 04/07/2023 at 14:23.
Pushed by sitter into branch 'master'.

kurlmimedata: don't portal symlinks

they are not really supported. from testing it seems that opening
O_NOFOLLOW results in the portal not being able to use the fd so
ultimately we have no way to copy a symlink (instead of the file it
points to)

M  +11   -3    src/lib/io/kurlmimedata.cpp

https://invent.kde.org/frameworks/kcoreaddons/-/commit/14e954248e365098e4b98cfd7c76e5ea1defb8a7
Comment 12 Harald Sitter 2023-07-04 14:35:04 UTC 
Git commit 2ec1a017b4cd0c56318b38ccd92b523ad21a1a08 by Harald Sitter.
Committed on 04/07/2023 at 14:28.
Pushed by sitter into branch 'kf5'.

kurlmimedata: don't portal symlinks

they are not really supported. from testing it seems that opening
O_NOFOLLOW results in the portal not being able to use the fd so
ultimately we have no way to copy a symlink (instead of the file it
points to)


(cherry picked from commit 14e954248e365098e4b98cfd7c76e5ea1defb8a7)

M  +11   -3    src/lib/io/kurlmimedata.cpp

https://invent.kde.org/frameworks/kcoreaddons/-/commit/2ec1a017b4cd0c56318b38ccd92b523ad21a1a08
Comment 13 Patrick Silva 2023-07-12 12:40:52 UTC 
*** Bug 472180 has been marked as a duplicate of this bug. ***
Comment 14 S. Christian Collins 2023-07-16 02:19:10 UTC 
This bug is marked as "fixed in 5.108", but I have KDE Frameworks 5.108.0 and I can still repro the bug exactly as in my original instructions. Unless the "5.108" version is incomplete or pertaining to something other than frameworks?
Comment 15 Nate Graham 2023-07-16 05:34:45 UTC 
My mistake sorry, it's fixed in 1.09, not 1.08.
Comment 16 Paul Worrall 2023-08-04 07:45:43 UTC 
*** Bug 472972 has been marked as a duplicate of this bug. ***
Comment 17 Jin Liu 2023-08-07 06:49:11 UTC 
Just realized that copy&paste *inside* Dolphin also involves a roundtrip to xdg-portal. Could it be better that Dolphin doesn't call xdg-portal when copy&paste from the same process (e.g. by putting the pid in the clipboard), so this very core functionality of a file manager doesn't depend on a (seemly buggy) third-party software?