Dolphin doesn't update its view unless I press F5?

If I have Dolphin open, showing a directory with a bunch of images, and then my unrelated script moves those images away, Dolphin doesn’t automatically “update the view”; I still see the images there in Dolphin until I hit F5.

I assume that it’s meant to detect any changes to the current view and update itself?

But if not, is there some terminal command that my script can run after it has moved the files in order to force Dolphin to detect that it has been changed?

How is the directory mounted? What file system?

If the file system is “local”, dolphin normally uses the inotify API to watch the directory, but that “does not catch remote events that occur on network filesystems”, among other cases.

For one of my cases, mounting a remote system with sshfs, if I identify the dolphin dbus session with qdbus | grep dolphin, I can tell it to refresh with

qdbus org.kde.dolphin-108356 /dolphin/Dolphin_1/actions/view_redisplay org.qtproject.Qt.QAction.trigger

Well, it’s simply a directory/folder on the desktop on the system drive, which was installed as ext4 (inside LUKS/LVM) by the Debian installer. So it’s not one of my additional drives which still use NTFS (for legacy reasons).

When trying that exact command, it says Service 'org.kde.dolphin-108356' does not exist., presumably meaning that it’s some sort of unique id which I’d have to find out, etc. Perhaps not the cleanest solution, but maybe the only one? I still don’t understand why it doesn’t detect it on its own, though.

I was too terse, I suppose. I did give a command that output the “unique id” (the number is the process id of the dolphin process):

qdbus | grep dolphin

or you could find the process id with

ps -e | grep dolphin

They don’t help choose between several dolphin instances. If you run X11, and install wmctrl, then

wmctrl -lp | grep 'Dolphin$'

On Wayland there’s kwin scripting, but I don’t know how to do that.

I now understand what you meant, and have figured out the right id for my test-Dolphin. Sadly, after my script has done its thing, and when I run the command in a terminal, nothing happens to the Dolphin window. It keeps showing the image file which is no longer actually there, until I press F5 manually. Sigh. :frowning:

You should post in Brainstorm about this and ask for the devs to look at adding this functionality. It can’t be that hard and it’s not like we don’t generally have the computing power needed nowadays.

That’s a case of 387663 – Dolphin doesn't update view (doesn't show new files) for local filesystem

You are using debian, so which versions of dolphin and kio are you using ?
They can be old especially for debian stable, and other component (default number of inotify watch) can worsen the situation.

You can run

cat /proc/sys/fs/inotify/max_user_watches

It should be 524288 on recent linux kernels.

I ask this because I have been working on this subject to help, and a few cases have been fixed, but I am still open to learn about the other circumstances that can happen.
You can help me debugging this, if you can reproduce this on recent dolphin version, and share your script and the precise scenario used.

The fact the qdbus command does not work seems to indicate you have an old setup or particular installation.

I can’t reproduce this issue on Kubuntu, MX and as far as I can tell, Sparky ( live).

kio/stable,now 5.103.0-1 amd64 [installed,automatic]
dolphin/stable,now 4:22.12.3-1 amd64 [installed,automatic]

cat /proc/sys/fs/inotify/max_user_watches

(Frankly, I don’t understand at all what “user watches” are.)

Also, I added some findings here: Dolphin should automatically reload views when they change

Just to chime in with a datapoint. I see this occasionally too, but I can’t reproduce if I try. E.g. I have bash script that just creates a lock-file, puts another file in that same directory and removes the lockfile afterwards.

touch "${lockfile}"
<do some stuff for a few milliseconds up to a few seconds which creates another file as a result>
rm "${lockfile}"

Now and then “afile.lock” stays around in the Dolpin window and only disappears after a F5. But it happens maybe 1 in a 100+.

max_user_watches is 524288. Up to date Arch install. Local btrfs volume.

brtfs mounted with noatime?

Yes, mounted with noatime.

1 Like

Does mounting it with atime makes any difference?

Maybe? :wink:

I’m not going to run my system with atime, so it would come down to a synthetic test, and yours is as good as mine.

Fair enough. Not using brtfs, btw, but I see if I can reproduce this behaviour on my machine somehow.

/e1: I set up a spare laptop to use UFS with noatime to see if I can reproduce this on FreeBSD. Will report back, if I see this behaviour

OK, I just had a 100% success triggering it. I tried to boil it down to a simple example which still seems to be around 20%.

Everything in here:

Thanks I do reproduce the issue with your script once every few runs on ext4 fs, ubuntu 23.10.

This will allow me to track the bug origin, might take some, wish me luck !


@meven keeping my fingers crossed.

@Schlaefer Thanks a lot!

@both I checked against FreeBSD but I don’t reproduce on UFS/noatime here, yet. (ran it 20times now). Will check again
with zfs as well, later.

1 Like

I have a merge request, anyone is welcome to try it although this is KF6 only.
It can be applied on top of KIO KF5, but we probably won’t ship the patch to KF5 as it is rather intrusive and adds some API, we will see.

I can’t reproduce the bug with your script anymore with the patch applied.


I can’t reproduce the bug with your script anymore with the patch applied.

Sound great. Can’t wait for plasma 6 to drop. :two_hearts: