SUMMARY With kio 5.249.0 I can no longer open plain text documents on my NFS share as they're lacking a file extension. Trying to set a default application also fails. An option to disable this behavior would be greatly appreciated. Reverting https://invent.kde.org/frameworks/kio/-/commit/8232925163748c31d95ccc3466a6790d325c3f08 solves the issue but is not really practical to have to re-compile the application for every version. STEPS TO REPRODUCE 1. Mount remote filesystem (sshfs, nfs) 2. Try to open or set default application for plain text file without extension 3. Dolphin etc will try to open it in some random application and no default can be set OBSERVED RESULT Extensionless files cannot be easily opened on remote filesystems EXPECTED RESULT kio should rely on mimetype when no extension is present, at the very least SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.93.0 KDE Frameworks Version: 5.249.0 Qt Version: 6.7.0 Kernel Version: 6.7.3-zen1-2-zen (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 3700X 8-Core Processor Memory: 47.0 GiB of RAM Graphics Processor: AMD Radeon RX 6600 XT Manufacturer: Gigabyte Technology Co., Ltd. Product Name: B450M DS3H
Ideally we may want to determine the mime types async, so that the main thread is not blocked.
(In reply to Magnus Boman from comment #0) > With kio 5.249.0 I can no longer open plain text documents on my NFS share I think you mean it's not that you can't open them at all by specifying a text editor manually, but that it doesn't open a file automatically through the default editor for text files. In general, the current behavior corresponds to the behavior of kio-fuse (protocols in dolphin like nfs://, webdav://) because it defines the type by extension via the Qt method `QMimeDatabase::mimeTypeForUrl` by remote url. > An option to disable this behavior would be greatly appreciated. This is of course one of the solutions, but I would like to suggest a different one. When you open the file, `KIO::OpenUrlJob` is executed by Dolphin, which in turn can call `KIO::MimeTypeFinderJob` to determine the mimetype (and this determination is more complicated than just by extension and, accordingly, defines a text file). The problem is that Dolphin calls the `KIO::OpenUrlJob` with an explicit indication of the mimetype that it defined earlier by extension - https://invent.kde.org/system/dolphin/-/commit/3b4676b3871cad5cd0e4695b211581f8db8accd0 (and mimetype most likely was determined here https://invent.kde.org/system/dolphin/-/blob/7f3967cf38f8ab707681981dd0bc6b220c3dbf83/src/kitemviews/kfileitemmodel.cpp#L1864, but it doesn't matter). This leads to the fact that `KIO::OpenUrlJob` does not call the `KIO::MimeTypeFinderJob`, and tries to open a file with the type "application/octet-stream". So, I suggest one of the following solutions: 1. If mimetype "application/octet-stream" and fileItem.isSlow() (so, it is this case with remote file with no extension) then call `KIO::OpenUrlJob` in Dolphin when opening a file without specifying the mimetype. If we do that, than `KIO::OpenUrlJob` will call `KIO::MimeTypeFinderJob` and determine mimetype, and I think it is okay to determine mimetype by content here, because we are opening file anyway and downloading a file for this here is not the same as downloading files in the background to determine the type when just opening a folder (like it was before PR with determining mimetypes from extensions for remote FS). 2. Determine the situation with mimetype "application/octet-stream" and fileItem.isSlow() inside `KIO::OpenUrlJob`, even if the "application/octet-stream" mimetype was specified explicitly when creating the job in Dolphin. I think first solution is a more suitable place, but the second solution may be able to solve a similar problem when this job is called not by Dolphin, but by some other program with the same purpose. After that, if we would open plain text file via click enter or mouse button, Dolphin will open file in default text editor.