| Summary: | copy/move symbolic link moves link destination instead | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kio | Reporter: | S. Christian Collins <s_chriscollins> |
| Component: | general | Assignee: | KIO Bugs <kio-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | a.samirh78, ad.liu.jin, elektorronikci, eridanired123, kde.h8bcay, kde, kdelibs-bugs, kfm-devel, kteleuth, lameventanas, nate, postix, prettyvanilla, r2b2x3+kdebug, rikiheck, riku, sam, sitter, tagwerk19, traceydick |
| Priority: | VHI | ||
| Version: | 5.102.0 | ||
| Target Milestone: | --- | ||
| Platform: | Neon | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/frameworks/kcoreaddons/-/commit/2ec1a017b4cd0c56318b38ccd92b523ad21a1a08 | Version Fixed In: | 5.109 |
| Sentry Crash Report: | |||
|
Description
S. Christian Collins
2023-01-13 06:18:11 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] 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. > 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.
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?) 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 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 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. *** Bug 469134 has been marked as a duplicate of this bug. *** 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/ A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/348 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 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 *** Bug 472180 has been marked as a duplicate of this bug. *** 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? My mistake sorry, it's fixed in 1.09, not 1.08. *** Bug 472972 has been marked as a duplicate of this bug. *** 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? |