Bug 456198 - Targets of relative symbolic links are resolved incorrectly in the status bar
Summary: Targets of relative symbolic links are resolved incorrectly in the status bar
Status: RESOLVED FIXED
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: git master
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KIO Bugs
URL:
Keywords:
: 461672 464326 465879 (view as bug list)
Depends on:
Blocks:
 
Reported: 2022-07-01 09:42 UTC by Paul Worrall
Modified: 2024-07-27 09:09 UTC (History)
10 users (show)

See Also:
Latest Commit: https://invent.kde.org/frameworks/kio/-/commit/7ba3f8c4462fb6ed3d7046c4933772b56c3ecce9
Version Fixed In: 6.5
Sentry Crash Report:

Attachments
A screenshot showing status bar v properties (380.15 KB, image/png)
2023-02-17 23:17 UTC, Mike Booth 		Details
Shows a folder as being symlinked to itself (102.44 KB, image/png)
2024-01-19 11:15 UTC, Alan Prescott 		Details
attachment-2790964-0.html (1.62 KB, text/html)
2024-06-26 09:09 UTC, Alan Prescott 		Details
attachment-3292567-0.html (2.01 KB, text/html)
2024-07-22 17:53 UTC, Alan Prescott 		Details
View All Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Worrall 2022-07-01 09:42:45 UTC 
STEPS TO REPRODUCE
1. Navigate in Dolphin to /var/spool
2. Hover over or select the item called "mail" (this is actually a symbolic link to "../mail")

OBSERVED RESULT
Status bar says it's a link to "file:///var/spool/mail" (i.e. a link to itself!)

EXPECTED RESULT
Status bar says it's a link to "file:///var/mail

SOFTWARE/OS VERSIONS
Operating System: KDE neon 5.25
KDE Plasma Version: 5.25.2
KDE Frameworks Version: 5.95.0
Qt Version: 5.15.5
Kernel Version: 5.13.0-51-generic (64-bit)
Graphics Platform: X11
Processors: 2 × AMD A6-6400K APU with Radeon(tm) HD Graphics
Memory: 7.7 GiB of RAM
Graphics Processor: AMD CEDAR
Manufacturer: NOVATECH LTD
Product Name: BB-64004H
System Version: V1.0
Comment 1 Paul Worrall 2022-08-21 08:11:09 UTC 
Probably another manifestation of the same bug:  When I right-click on a relative symbolic link and choose "Show Target", it still shows the link.

Note: Symbolic links with absolute path are resolved correctly.
Comment 2 Paul Worrall 2023-02-17 09:45:15 UTC 
*** Bug 465879 has been marked as a duplicate of this bug. ***
Comment 3 Mike Booth 2023-02-17 23:17:51 UTC 
Created attachment 156404 [details]
A screenshot showing status bar v properties
Comment 4 Mike Booth 2023-02-21 22:55:58 UTC 
If its any help Konqueror exhibits the same problem
Comment 5 Méven Car 2023-03-23 11:34:46 UTC 
Issue is in KfileItem::StatusBarText
Comment 6 Bug Janitor Service 2023-03-23 11:38:46 UTC 
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/1237
Comment 7 Méven 2023-04-20 10:16:27 UTC 
Git commit 28f94469ac08e0c3aedf541debbcd97901009ed1 by Méven Car.
Committed on 20/04/2023 at 09:19.
Pushed by meven into branch 'master'.

KFileItem StatusBarText: Better resolve relative symlink path

M  +31   -0    autotests/kfileitemtest.cpp
M  +6    -3    src/core/kfileitem.cpp

https://invent.kde.org/frameworks/kio/commit/28f94469ac08e0c3aedf541debbcd97901009ed1
Comment 8 Jonathan Marten 2023-07-14 14:46:13 UTC 
*** Bug 461672 has been marked as a duplicate of this bug. ***
Comment 9 Méven Car 2023-08-22 08:32:24 UTC 
*** Bug 464326 has been marked as a duplicate of this bug. ***
Comment 10 Alan Prescott 2024-01-19 11:15:14 UTC 
Created attachment 165034 [details]
Shows a folder as being symlinked to itself

The correct symlink target should be "Folder, link to /home/alan/snap/pycharm-community/360"
Comment 11 medin 2024-01-19 22:34:18 UTC 
I confirm the same problem on Manjaro/KDE Plasma 5.27.10
Comment 12 Alan Prescott 2024-03-29 08:35:01 UTC 
Just checked this out again today on most recent openSUSE Tumbleweed updates with Plasma6/Wayland

It appears that symlinks to absolute paths are reported correctly but symlinks to relative paths are not

Operating System: openSUSE Tumbleweed 20240327
KDE Plasma Version: 6.0.2
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.8.1-1-default (64-bit)
Graphics Platform: Wayland
Comment 13 Paul Worrall 2024-06-24 15:38:05 UTC 
Seems to be OK now.

Operating System: Arch Linux 
KDE Plasma Version: 6.1.0
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.2
Comment 14 Alan Prescott 2024-06-26 09:03:55 UTC 
Absolute symlinks are OK

Relative symlinks show the target as an absolute path (using '~' if the target is in the user's home folder)

So, better, but not quite right in Plasma 6.0.5 - I will check again when openSUSE Tumbleweed goes to Plasma 6.1

Operating System: openSUSE Tumbleweed 20240621
KDE Plasma Version: 6.0.5
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.1
Comment 15 Alan Prescott 2024-06-26 09:09:45 UTC 
Created attachment 171001 [details]
attachment-2790964-0.html

Are relative symlink targets showing as relative or absolute paths?

Alan Prescott
alanjprescott@gmail.com


On Mon, 24 Jun 2024 at 18:38, Paul Worrall <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=456198
>
> Paul Worrall <p.r.worrall@gmail.com> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>          Resolution|---                         |FIXED
>              Status|REOPENED                    |RESOLVED
>
> --- Comment #13 from Paul Worrall <p.r.worrall@gmail.com> ---
> Seems to be OK now.
>
> Operating System: Arch Linux
> KDE Plasma Version: 6.1.0
> KDE Frameworks Version: 6.3.0
> Qt Version: 6.7.2
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 16 Alan Prescott 2024-06-26 10:30:50 UTC 
Just upgraded to Plasma 6.1.0 on openSUSE Tumbleweed

Relative symlinks are showing targets as absolute paths so I'm reopening this bug
Comment 17 Luca Saalfeld 2024-06-26 10:37:29 UTC 
(In reply to Alan Prescott from comment #16)

> Relative symlinks are showing targets as absolute paths

Isn't this what it's supposed to do? The symlink points to that file and the target is shown as it's path.
If a relative link should show a relative path that seems more like a new feature rather than this bug.
Comment 18 Alan Prescott 2024-06-27 14:24:18 UTC 
You are correct in that the target is the same whether the symlink is absolute or relative  but, personally, I'd have thought that the path displayed would be the same as if I'd typed `ls -l`. 
If the link always shows as an absolute path then we're missing the chance to provider the user with available information which (s)he will have to go to a terminal window to find out.
Comment 19 Bug Janitor Service 2024-07-22 14:20:22 UTC 
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/1664
Comment 20 Méven Car 2024-07-22 14:21:02 UTC 
(In reply to Alan Prescott from comment #18)
> You are correct in that the target is the same whether the symlink is
> absolute or relative  but, personally, I'd have thought that the path
> displayed would be the same as if I'd typed `ls -l`. 
> If the link always shows as an absolute path then we're missing the chance
> to provider the user with available information which (s)he will have to go
> to a terminal window to find out.

This isn't really practical: if you have expanded folders, with a pointing being a relative symlink, how should the path be resolved relative to ?
The root expanded folder ? The folder containing the the file ?

For instance
/a/afile
/b/afile -> ../a/afile

And with / opened with folder opened what should the status bar show when hovering over /b/afile ?
The only systematic clear answer is absolute path.
We can still tilde collapse it though.
Comment 21 Alan Prescott 2024-07-22 17:53:08 UTC 
Created attachment 171901 [details]
attachment-3292567-0.html

I would have thought that it should reflect the output from `ls -l`

Alan Prescott
alanjprescott@gmail.com


On Mon, 22 Jul 2024 at 17:21, Méven Car <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=456198
>
> --- Comment #20 from Méven Car <meven29@gmail.com> ---
> (In reply to Alan Prescott from comment #18)
> > You are correct in that the target is the same whether the symlink is
> > absolute or relative  but, personally, I'd have thought that the path
> > displayed would be the same as if I'd typed `ls -l`.
> > If the link always shows as an absolute path then we're missing the
> chance
> > to provider the user with available information which (s)he will have to
> go
> > to a terminal window to find out.
>
> This isn't really practical: if you have expanded folders, with a pointing
> being a relative symlink, how should the path be resolved relative to ?
> The root expanded folder ? The folder containing the the file ?
>
> For instance
> /a/afile
> /b/afile -> ../a/afile
>
> And with / opened with folder opened what should the status bar show when
> hovering over /b/afile ?
> The only systematic clear answer is absolute path.
> We can still tilde collapse it though.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 22 Méven Car 2024-07-25 12:08:56 UTC 
(In reply to Alan Prescott from comment #21)
> Created attachment 171901 [details]
> attachment-3292567-0.html
> 
> I would have thought that it should reflect the output from `ls -l`
> 
> Alan Prescott
> alanjprescott@gmail.com
> 
> 
> On Mon, 22 Jul 2024 at 17:21, Méven Car <bugzilla_noreply@kde.org> wrote:
> 
> > https://bugs.kde.org/show_bug.cgi?id=456198
> >
> > --- Comment #20 from Méven Car <meven29@gmail.com> ---
> > (In reply to Alan Prescott from comment #18)
> > > You are correct in that the target is the same whether the symlink is
> > > absolute or relative  but, personally, I'd have thought that the path
> > > displayed would be the same as if I'd typed `ls -l`.
> > > If the link always shows as an absolute path then we're missing the
> > chance
> > > to provider the user with available information which (s)he will have to
> > go
> > > to a terminal window to find out.
> >
> > This isn't really practical: if you have expanded folders, with a pointing
> > being a relative symlink, how should the path be resolved relative to ?
> > The root expanded folder ? The folder containing the the file ?
> >
> > For instance
> > /a/afile
> > /b/afile -> ../a/afile
> >
> > And with / opened with folder opened what should the status bar show when
> > hovering over /b/afile ?
> > The only systematic clear answer is absolute path.
> > We can still tilde collapse it though.
> >
> > --
> > You are receiving this mail because:
> > You are on the CC list for the bug.

I have remade my patch, it is now compliant with what you expect.
This still makes sense to show the relative path, it will be relative to the file location as with `ls -/`.

 https://invent.kde.org/frameworks/kio/-/merge_requests/1664
Comment 23 Méven 2024-07-27 09:00:42 UTC 
Git commit 7ba3f8c4462fb6ed3d7046c4933772b56c3ecce9 by Méven Car.
Committed on 27/07/2024 at 09:00.
Pushed by meven into branch 'master'.

kfileitem: show relative path for rel symlink

 * Use readlink in linkDest based on file_unix implementation
 * tilde collapse absolute path in StatusBarInfo().
 * Fix test KFileItemTest::testPermissionsString

M  +31   -10   autotests/kfileitemtest.cpp
M  +46   -1    src/core/kfileitem.cpp

https://invent.kde.org/frameworks/kio/-/commit/7ba3f8c4462fb6ed3d7046c4933772b56c3ecce9