The issue could be as well located in previewjob.cpp.
Could you debug why KMountPoint::List::findByPath is called with an empty string or non-existing file.
We might want to prevent this to happen instead.

Are you not seeing these for instance when browsing an MSWin share in Dolphin (with the same or newer versions of kio-extras, Samba and MSWin)?

I tried to figure out where they came from but failed because of the async nature of the chain of events. I presume the empty paths come from the smb KIO plugin and then somehow make it to where the warning is printed.
I also considered that findByPath() already accepts non-existing paths and handles them appropriately, it could (and probably should) do the same with an empty path. Regardless of the fact that the smb plugin probaby shouldn't output empty paths; maybe the maintainer(s) of that software should be CC'ed here?

In D22801#561989, @rjvbb wrote:

Are you not seeing these for instance when browsing an MSWin share in Dolphin (with the same or newer versions of kio-extras, Samba and MSWin)?ç

I don't have a samba (or MS) share available currently, unfortunately I can't test, but I might later.

I tried to figure out where they came from but failed because of the async nature of the chain of events. I presume the empty paths come from the smb KIO plugin and then somehow make it to where the warning is printed.

I would suggest adding a dumb qDebug() appriopriately or panic whenever findByPath is called with an emtpy path.
In previewjob.cpp What was PreviewJobPrivate KFileItemList initialItems when this happened ?

I also considered that findByPath() already accepts non-existing ppathsaths and handles them appropriately, it could (and probably should) do the same with an empty path.

I disagree since it will change the current precondition of the function for the need of one of its users.
A warning is an explicit indication that assumption made writing the code are broken either because they are overstepped or were too limited when writing the code.

findPath is documented as :

/**
 * Find the mountpoint on which resides @p path
 * For instance if /home is a separate partition, findByPath("/home/user/blah")
 * will return /home
 * @param path the path to check
 * @return the mount point of the given file
 */
Ptr findByPath(const QString &path) const;

It makes no sense to check the mountpoint of an empty path that by essence cannot be a file.
This might hide others bugs elsewhere.

Regardless of the fact that the smb plugin probaby shouldn't output empty paths; maybe the maintainer(s) of that software should be CC'ed here?

KIO is an old code-base and is maintained collectively mostly (with a single main maintainer @dfaure), we need to use our own wits.

Btw do you use a samba mount(/etc/fstab defined or mount -t smb) or the smb:// ioslave ? You must mean the smb:// ioslave with smb plugin.
In which case we might want to check the samba kio-extras code as well, in particular SMBSlave::listDir that returns the files contained in a folder.
Does it returns files with empty urls ?

I disagree since it will change the current precondition of the function for the need of one of its users.

In that case the warning could be made to be a qDebug, and that user can configure his/her logging setting so the category used will always be printed.
That user might also be served much better by an error return that his/her code could work with, rather than with a terminal warning (which will not be seen by anyone NOT using a terminal to launch applications.

findPath is documented as :

IOW, there is no documentation requirement that warnings be printed for empty path arguments.

It makes no sense to check the mountpoint of an empty path that by essence cannot be a file.

It makes no sense to do that check for any string that is not a valid path. Yet (from memory) there is a specific warning for this particular kind of invalid path.

KIO is an old code-base and is maintained collectively mostly (with a single main maintainer @dfaure), we need to use our own wits.

The smb plugin is part of kio-extras.

Does it returns files with empty urls ?

I have no idea how to check that (other than inserting trace output into smb.so), but I reckon the empty paths must indeed come from there.

I might (if I can find the trouble location) but IMHO KIO should still account for the possibility of this situation too (or more in general, bail out this function for any path that cannot be a mountpoint).

I disagree. Invalid method call, you get a warning already from Qt, no need to bloat this method more.

Whatever, I'm staying at 5.60.0 anyway, with whatever patches I deem appropriate.