SUMMARY when kcoredirlister gets a FileRenamedWithLocalPath or FilesChanged signal on a file that doesn't exist in its model it doesn't try to stat the file and potentially add it to the model leading to the internal model potentially getting out of sync with the real directory state depending on signal order. specifically over SMB renaming a file on a windows 10 host always issues a deletion event before the actual move event. this leads to the original file getting kicked out of the model and when the actual move event arrives it gets discard because it is concerning unknown files. at this point I'd expect the lister to actually schedule a new stat on the (now) unknown files to ascertain if they exist and what they are and bring them into the model. this specifically applies to FilesChanged. if a file changes that we don't know about, clearly we should at least check what's up with that. bug #430585 has a bit of extra context. actual notification order from smb: signal time=1611157682.777775 sender=:1.3315 -> destination=(null destination) serial=19 path=/; interface=org.kde.KDirNotify; member=FilesRemoved array [ string "smb://user@windev2004eval.local/Users/User/Desktop/New folder (6)/a" ] signal time=1611157682.778322 sender=:1.3315 -> destination=(null destination) serial=20 path=/; interface=org.kde.KDirNotify; member=FileRenamed string "smb://user@windev2004eval.local/Users/User/Desktop/New folder (6)/a" string "smb://user@windev2004eval.local/Users/User/Desktop/New folder (6)/A" signal time=1611157682.778640 sender=:1.3315 -> destination=(null destination) serial=22 path=/; interface=org.kde.KDirNotify; member=FilesChanged array [ string "smb://user@windev2004eval.local/Users/User/Desktop/New folder (6)/A" ] STEPS TO REPRODUCE 1. undo the smb-notifier change related to bug #430585 and restart kded 2. open a SMB dir hosted on a windows 10 machine 3. make file a 4. rename a to A OBSERVED RESULT file disappeared from view because the internal model is out of sync with the reality on disk EXPECTED RESULT the file 'A' should exist. more generally: when dirlister gets a notification that doesn't add up to the internal state of affairs it should try to reconcile by either reloading everything or stat the questionable paths