SUMMARY This can be demonstarted by trying to open a directory, either directly or via a Type=Link desktop file, which refers to a symbolic link. The link is not followed which means that an incorrect (or no) MIME type is returned. This happens when launching such a desktop file from the Plasma desktop, but it can be reproduced from the command line. STEPS TO REPRODUCE 1. Set up test directories/symlinks as follows: drwxr-xr-x 2 user users 40 May 6 20:46 /tmp/a/ lrwxrwxrwx 1 user users 1 May 6 20:46 /tmp/b -> a/ 2. Execute 'kioclient5 exec file:///tmp/a' ==> The directory /tmp/a is opened in the default file manager 3. Execute 'kioclient5 exec file:///tmp/b' ==> No file manager is started An error box saying simply "/tmp/b" is displayed A debug message is shown: kioclient KIO::MimeTypeFinderJobPrivate::scanFileWithGet()::<lambda: KIO::get didn't emit a mimetype! Please fix the ioslave for URL QUrl("file:///tmp/b") OBSERVED RESULT Failure as in (3) above EXPECTED RESULT In (3) above the directory /tmp/b should be opened in the default file manager. SOFTWARE/OS VERSIONS Operating System: Gentoo KDE Plasma Version: 5.21.80 KDE Frameworks Version: 5.82.0 Qt Version: 5.15.2 Kernel Version: 5.10.27-gentoo-x86_64 (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION These desktop files, if placed on the Plasma desktop, will give the same results when launched. ok.desktop: [Desktop Entry] Type=Link URL[$e]=file:///tmp/a fail.desktop: [Desktop Entry] Type=Link URL[$e]=file:///tmp/b
Replacing the KIO::StatBasic near the start of KIO::MimeTypeFinderJobPrivate::statFile() with KIO::StatBasic||KIO::StatResolveSymlink fixes the problem, but I don't know if there are other implications if doing this.
Might make sense to open a merge request and ask again in there.
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/442