https://bugs.kde.org/show_bug.cgi?id=525084
Bug ID: 525084
Summary: "Link Here" writes the navigated (non-canonical) path
instead of the resolved path, producing symlinks that
silently fail with strict downstream consumers (e.g.
Samba wide links)
Classification: Applications
Product: dolphin
Version First unspecified
Reported In:
Platform: Fedora RPMs
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
Description:
When creating a symlink via Dolphin's "Link Here" (or when copying a path from
the address bar for use elsewhere), Dolphin writes the literal path used to
navigate to the file/folder — including any symlink components traversed along
the way — rather than the canonical (fully resolved) path to the same location.
Steps to reproduce:
1. Have a symlink A in your home directory pointing to some other directory B
(e.g. ~/Documents/finance -> /srv/hpssd/finance).
2. In Dolphin, navigate into ~/Documents/finance/... (i.e. browse through the
symlink A, not directly via B).
3. Select a file or folder there, and use "Link Here" (or copy as path) to
create a new symlink to it elsewhere.
Observed behavior:
The resulting symlink's target is written as /home/user/Documents/finance/... —
the path as navigated — even though the underlying location is really
/srv/hpssd/finance/....
Expected behavior:
The symlink target should be the canonical/resolved path (equivalent to
readlink -f / realpath), since a symlink is meant to be a durable, unambiguous
pointer to a location — not a record of how the user happened to browse there.
Why this matters (real-world impact):
Both paths are valid and resolve to the same file from a plain shell/local
perspective, so the problem isn't obvious at creation time. It only surfaces
later, with tools that treat the literal path text as meaningful rather than
resolving it fully:
- Samba, when serving the directory containing B (e.g. /srv/hpssd/finance) as a
share, applies a "wide links" security check that compares the literal target
path string against the share root. A target written as
/home/user/Documents/finance/... fails that check (even though it's the same
file as /srv/hpssd/finance/...), and Samba silently omits the entry from
directory listings — no error, just an invisible file/folder to network
clients.
- Similar issues can arise with backup tools, rsync --copy-links scenarios, or
any tool that reasons about "is this path inside directory X" using string
comparison rather than full resolution.
The bug is that Dolphin, which has full context at the moment of link creation
(including cheap access to the resolved path via readlink -f), commits an
ambiguous/non-canonical path to permanent storage instead of the unambiguous
one. Downstream consumers can't reasonably be expected to guess that two
different path strings might refer to the same location — that's a decision
that belongs at creation time, not at every point of later consumption.
Suggested fix:
Canonicalize the source path (resolve all symlink components) before writing it
as the new symlink's target in "Link Here". If preserving the current behavior
is desired for some use cases, consider adding it as a secondary option ("Link
Here (canonical path)" vs the current default), or a setting.
Environment:
Dolphin version: [paste from Step 1]
KDE Frameworks version: [paste from Step 1]
Distro: [paste from Step 1]
SOFTWARE/OS VERSIONS
$ kinfo
Operating System: Fedora Linux 43
KDE Plasma Version: 6.7.4
KDE Frameworks Version: 6.29.0
Qt Version: 6.10.3
Kernel Version: 7.1.10-100.fc43.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 32 × Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz
Memory: 96 GiB of RAM (94.3 GiB usable)
Graphics Processor: NVIDIA TITAN Xp
ADDITIONAL INFORMATION
--
You are receiving this mail because:
You are watching all bug changes.
