Links to smb shares (e.g. in mails or direct input in location bar) are working if the target is a directory. But if the target is a file dolphin tries to open it as a directory and fails. Dolphin should test if the target is a file and should open it with the default application or ask the user. This is working: smb://hostname/share/ This is not working: smb://hostname/share/filename.pdf Thanks!
Is that how you usually open files (pasting their URI into dolphin), or did you do that as a result of another bug that lead you to try dolphin?
Usually we open files by opening the smb server shared path and clicking on files in dolphin. But there is another use case: We have samba shared folders on our servers and PDFs or other text files for the users to read before they should use these folders or just containing information about their files. In several cases our users are informed by automatically generated mails about their data on the shares and the way how to use shares (e.g. filename conventions). In these emails there are smb links to the users shared folders and to the readme pdf/txt files with more detailed information. So users can click on the smb links in their mail client to open their shared folders directly on the server. It would be great if they also could click on the readme or other files which are linked in the mails to open directly (like smb://hostname/share/filename.pdf). Currently in produces an error because dolphin tries to open the smb linkded file as a directory shared name. The system is configured to open smb links in mails with dolphin as this works great for directory shares and would be more great and more consistent to also open smb linked files.
What you describe is how a sound mail client would/will/does work though. You really shouldn't force smb to open with dolphin specifically. You should delegate the opening to actual "opening" technology, which dolphin is not. e.g. `xdg-open` or `kioclient5 exec` both will correctly open any URI, be it directory or file, with the relevant application as per the URI's mimetype. So, if the URI points to a shared directory it will open in dolphin, if it points to a pdf it will open in a PDF reader and so on and so forth. Or to put it very simply: dolphin doesn't register for any file mimetypes, so it can rightly expect to not ever be called with file URIs (some exceptions apply; I am sure). Funneling all URIs through dolphin is at best suuuuuuuuuuuuuuuper inefficient because you are forking a GUI app to carry out the job of opening a resource for which it will ultimately, likely, not be responsible. At worst it blows up in ways like the one you describe because dolphin is not designed to be a file opener. That being said, I am rather thinking this bug is in Dolphin not SMB KIO. The higher level application should query the mimetype from smb and then carry out an action based on the result. Dolphin probably just wants to call listdir and gets back that error. Needs some investigation.
Bouncing bug to dolphin. This isn't a problem with SMB. What happens is that DolphinView calls DolphinView::loadDirectory which as the name suggests loads the directory which translates to listDir() on the SMB side, SMB goes "uhh, that's not a dir". Dolphin displays that message and gives up. As mentioned though, there's an argument to be made that this is perfectly reasonable behavior for dolphin as it is simply not the piece of software meant to run arbitrary urls.