| Summary: | Targets of relative symbolic links are resolved incorrectly in the status bar | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kio | Reporter: | Paul Worrall <p.r.worrall> |
| Component: | general | Assignee: | KIO Bugs <kio-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alanjprescott, kdelibs-bugs, kfm-devel, luluklzde, med.medin.2014, meven29, mikebooth76, post, tagwerk19, wl |
| Priority: | NOR | ||
| Version: | git master | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| See Also: |
https://bugs.kde.org/show_bug.cgi?id=462269 https://bugs.kde.org/show_bug.cgi?id=461672 |
||
| 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
Shows a folder as being symlinked to itself attachment-2790964-0.html attachment-3292567-0.html |
||
|
Description
Paul Worrall
2022-07-01 09:42:45 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. *** Bug 465879 has been marked as a duplicate of this bug. *** Created attachment 156404 [details]
A screenshot showing status bar v properties
If its any help Konqueror exhibits the same problem Issue is in KfileItem::StatusBarText A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/1237 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 *** Bug 461672 has been marked as a duplicate of this bug. *** *** Bug 464326 has been marked as a duplicate of this bug. *** 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"
I confirm the same problem on Manjaro/KDE Plasma 5.27.10 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 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 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 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. Just upgraded to Plasma 6.1.0 on openSUSE Tumbleweed Relative symlinks are showing targets as absolute paths so I'm reopening this bug (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. 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. A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/1664 (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. 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. (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 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 |