Created attachment 128741 [details] Emptying trash does not trigger refresh When I click on Empty Trash inside Dolphin, the folder view is not updated to reflect the deleted content. See my video for more info. Operating System: Manjaro Linux KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.70.0 Qt Version: 5.14.2 Kernel Version: 5.6.12-1-MANJARO OS Type: 64-bit Processors: 2 × Pentium® Dual-Core CPU T4400 @ 2.20GHz Memory: 5.7 GiB of RAM
I don't reproduce. Do you have inotify installed and working ? When you move files using the terminal, is it reflected in dolphin automatically ?
(In reply to Méven Car from comment #1) > I don't reproduce. > > Do you have inotify installed and working ? > > When you move files using the terminal, is it reflected in dolphin > automatically ? By inotify do you mean the package inotify-tools I don't have it installed and I never removed it. And in settings I have some service called "Directory Watcher" which is reported to be running. When I move/rename files by command line the change is reflected to dolphin opened window. This problem is not present when I select files in Trash folder and click on delete keyboard then Delete, it's only present when using "Empty Trash" button from Dolphin.
Even after installing inotify-tools package then rebooting, the problem is still persistent. This bug is probably introduced in the latest Manjaro KDE stable update of 19/05/2020.
Same for me on Fedora 30 and now on 32 after an upgrade.
(In reply to enenou from comment #4) > Same for me on Fedora 30 and now on 32 after an upgrade. What solved the problem for me is to do rm -rf ~/.local/share/Trash/ then reboot
I can confirm this on Debian GNU/Linux testing: Operating System: Debian GNU/Linux KDE Plasma Version: 5.17.5 KDE Frameworks Version: 5.70.0 Qt Version: 5.14.2 Kernel Version: 5.7.0-1-amd64 OS Type: 64-bit Processors: 8 × AMD FX(tm)-8150 Eight-Core Processor Memory: 31.3 GiB of RAM Dolphin version: 20.04.2 As for the inotify-tools package I installed: Package: inotify-tools Version: 3.14-8.1 Priority: optional Section: misc Maintainer: Dmitry Bogatov <KAction@debian.org> I have been able to see the described trash behavior without inotify-tools package installed and with inotify-tools package installed. Nothing was fixed after installing inotify-tools and rebooting. I can reproduce this with: - a new volume (a HD formatted with ext4) - a local SMB-mounted network volume I can get the proper trash+auto-refresh behavior to work once the first time I empty the trash in a session. After that, it fails in exactly the same way as shown in the attached screengrab. I'll try what was mentioned in comment 5 ("rm -rf ~/.local/share/Trash/ then reboot") and report back if that fixes things, but I don't understand why that would work at all.
I can also confirm this: Operating System: Arch Linux KDE Plasma Version: 5.20.3 KDE Frameworks Version: 5.75.0 Qt Version: 5.15.1 Kernel Version: 5.9.8-arch1-1 OS Type: 64-bit Processors: 4 × Intel® Core™ i5-4300M CPU @ 2.60GHz Memory: 7,7 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4600 Dolphin version: 20.08.3 I am able to resolve the problem using the command mentioned in comment 5. In my case I do not have inotify installed.
Currently not able to reproduce with my setup. Can send a few files to the trash, delete, view refreshes. Also able to repeat this several times and the view refreshes. Operating System: Fedora 33 KDE Plasma Version: 5.19.5 KDE Frameworks Version: 5.75.0 Qt Version: 5.15.1 Kernel Version: 5.9.8-300.fc33.x86_64 OS Type: 64-bit Dolphin Version: 20.8.3
This happens again with 5.20.5, It's tiring to always remove ~/.local/share/Trash/ by hand after certain usage time.
(In reply to medin from comment #9) > This happens again with 5.20.5, It's tiring to always remove > ~/.local/share/Trash/ by hand after certain usage time. Have you checked your inotify capacities ? Its default value is quite low and some programs like IDE or VM need of lot of inofity resources. See for instance https://unix.stackexchange.com/questions/13751/kernel-inotify-watch-limit-reached
(In reply to Méven Car from comment #10) > (In reply to medin from comment #9) > > This happens again with 5.20.5, It's tiring to always remove > > ~/.local/share/Trash/ by hand after certain usage time. > > Have you checked your inotify capacities ? > Its default value is quite low and some programs like IDE or VM need of lot > of inofity resources. > > See for instance > https://unix.stackexchange.com/questions/13751/kernel-inotify-watch-limit- > reached I set : fs.inotify.max_user_watches = 524288 then rebooted, but the same problem persists.
possibly duplicate of bug 387663
*** Bug 442202 has been marked as a duplicate of this bug. ***
(In reply to medin from comment #11) > (In reply to Méven Car from comment #10) > > (In reply to medin from comment #9) > > > This happens again with 5.20.5, It's tiring to always remove > > > ~/.local/share/Trash/ by hand after certain usage time. > > > > Have you checked your inotify capacities ? > > Its default value is quite low and some programs like IDE or VM need of lot > > of inofity resources. > > > > See for instance > > https://unix.stackexchange.com/questions/13751/kernel-inotify-watch-limit- > > reached > > I set : > fs.inotify.max_user_watches = 524288 > then rebooted, but the same problem persists. Can you check which process are consuming the inotify watches resources, this stack overflow answer provides a handy script inotify-consumers.sh that does just that : https://unix.stackexchange.com/questions/15509/whos-consuming-my-inotify-resources/502812#502812 If that is dolphin, then there must be some particular circumstances due to your systems, how many tabs and instances are opened.
*** Bug 443602 has been marked as a duplicate of this bug. ***
Still happening for me too after so long. Dolphin 22.08.0
I don't reproduce this in Dolphin 22.12. Can anyone still reproduce it ?
*** Bug 431034 has been marked as a duplicate of this bug. ***
(In reply to Méven Car from comment #17) > I don't reproduce this in Dolphin 22.12. > > Can anyone still reproduce it ? It is still happening for me. In an open dolphin windows I have a wastebin icon under the places list. WHen i right click and select empty wastebin the bin doesnt empty and the icon doesnt change unless i physically click the icon to open it in the dolphin window and refresh the contents Operating System: KDE neon Testing Edition KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.8 Kernel Version: 6.2.10-1-liquorix-amd64 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-4460 CPU @ 3.20GHz Memory: 15.6 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1050 Ti/PCIe/SSE2 Manufacturer: Gigabyte Technology Co., Ltd. Product Name: H81M-S2H
(In reply to adec2011.ac from comment #19) > (In reply to Méven Car from comment #17) > > I don't reproduce this in Dolphin 22.12. > > > > Can anyone still reproduce it ? > > It is still happening for me. > > In an open dolphin windows I have a wastebin icon under the places list. > WHen i right click and select empty wastebin the bin doesnt empty and the > icon doesnt change unless i physically click the icon to open it in the > dolphin window and refresh the contents > > Operating System: KDE neon Testing Edition > KDE Plasma Version: 5.27.4 > KDE Frameworks Version: 5.105.0 > Qt Version: 5.15.8 > Kernel Version: 6.2.10-1-liquorix-amd64 (64-bit) > Graphics Platform: X11 > Processors: 4 × Intel® Core™ i5-4460 CPU @ 3.20GHz > Memory: 15.6 GiB of RAM > Graphics Processor: NVIDIA GeForce GTX 1050 Ti/PCIe/SSE2 > Manufacturer: Gigabyte Technology Co., Ltd. > Product Name: H81M-S2H Just to add my dolphin is Version 23.03.90
(In reply to adec2011.ac from comment #20) > (In reply to adec2011.ac from comment #19) > > (In reply to Méven Car from comment #17) > > > I don't reproduce this in Dolphin 22.12. > > > > > > Can anyone still reproduce it ? > > > > It is still happening for me. > > > > In an open dolphin windows I have a wastebin icon under the places list. > > WHen i right click and select empty wastebin the bin doesnt empty and the > > icon doesnt change unless i physically click the icon to open it in the > > dolphin window and refresh the contents > > > > Operating System: KDE neon Testing Edition > > KDE Plasma Version: 5.27.4 > > KDE Frameworks Version: 5.105.0 > > Qt Version: 5.15.8 > > Kernel Version: 6.2.10-1-liquorix-amd64 (64-bit) > > Graphics Platform: X11 > > Processors: 4 × Intel® Core™ i5-4460 CPU @ 3.20GHz > > Memory: 15.6 GiB of RAM > > Graphics Processor: NVIDIA GeForce GTX 1050 Ti/PCIe/SSE2 > > Manufacturer: Gigabyte Technology Co., Ltd. > > Product Name: H81M-S2H > > Just to add my dolphin is Version 23.03.90 It looks like you're running Neon, which has kde-inotify-survey packaged. That package installs a notifier module, but also a commandline utility that outputs the current inotify usage as a json file. If you were to run kde-inotify-survey in Konsole immediately after reproducing the issue and paste the results into a reply here, it might help diagnose the problem.
It's still happening for me too. Operating System: Arch Linux KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.2.10-arch1-1 (64-bit) Dolphin: 22.12.3
OK, I have run kde-notify-survey just after i try to empty the trash from within dolphin and i get this output { "processes": [ { "cmdline": "/lib/systemd/systemd", "instances": 3, "pid": 1835, "uid": 1000, "watches": 85 }, { "cmdline": "/usr/bin/gamemoded", "instances": 1, "pid": 1852, "uid": 1000, "watches": 4 }, { "cmdline": "/usr/bin/pulseaudio", "instances": 2, "pid": 1854, "uid": 1000, "watches": 2 }, { "cmdline": "/usr/bin/dbus-daemon", "instances": 1, "pid": 1865, "uid": 1000, "watches": 6 }, { "cmdline": "/usr/bin/startplasma-x11", "instances": 1, "pid": 1875, "uid": 1000, "watches": 0 }, { "cmdline": "/usr/bin/ibus-daemon", "instances": 1, "pid": 1974, "uid": 1000, "watches": 1 }, { "cmdline": "/usr/libexec/ibus-dconf", "instances": 1, "pid": 1985, "uid": 1000, "watches": 1 }, { "cmdline": "/usr/libexec/ibus-ui-gtk3", "instances": 1, "pid": 1991, "uid": 1000, "watches": 2 }, { "cmdline": "/usr/libexec/ibus-extension-gtk3", "instances": 1, "pid": 1993, "uid": 1000, "watches": 2 }, { "cmdline": "/usr/libexec/ibus-x11", "instances": 1, "pid": 1996, "uid": 1000, "watches": 2 }, { "cmdline": "/usr/libexec/ibus-portal", "instances": 1, "pid": 1999, "uid": 1000, "watches": 1 }, { "cmdline": "/usr/bin/dbus-daemon", "instances": 1, "pid": 2015, "uid": 1000, "watches": 1 }, { "cmdline": "/usr/libexec/xdg-desktop-portal", "instances": 1, "pid": 2021, "uid": 1000, "watches": 1 }, { "cmdline": "/usr/libexec/ibus-engine-simple", "instances": 1, "pid": 2031, "uid": 1000, "watches": 1 }, { "cmdline": "/usr/libexec/xdg-desktop-portal-gtk", "instances": 1, "pid": 2053, "uid": 1000, "watches": 58 }, { "cmdline": "/usr/lib/x86_64-linux-gnu/libexec/xdg-desktop-portal-kde", "instances": 1, "pid": 2065, "uid": 1000, "watches": 1 }, { "cmdline": "/usr/bin/plasma_session", "instances": 1, "pid": 2095, "uid": 1000, "watches": 0 }, { "cmdline": "/usr/lib/x86_64-linux-gnu/libexec/kf5/klauncher", "instances": 1, "pid": 2102, "uid": 1000, "watches": 1 }, { "cmdline": "/usr/bin/kded5", "instances": 4, "pid": 2114, "uid": 1000, "watches": 497 }, { "cmdline": "/usr/bin/kwin_x11", "instances": 1, "pid": 2117, "uid": 1000, "watches": 1 }, { "cmdline": "/usr/bin/ksmserver", "instances": 2, "pid": 2121, "uid": 1000, "watches": 1 }, { "cmdline": "/usr/bin/kglobalaccel5", "instances": 1, "pid": 2122, "uid": 1000, "watches": 1 }, { "cmdline": "/usr/bin/xembedsniproxy", "instances": 1, "pid": 2128, "uid": 1000, "watches": 1 }, { "cmdline": "/usr/lib/x86_64-linux-gnu/libexec/baloo_file", "instances": 3, "pid": 2129, "uid": 1000, "watches": 20771 }, { "cmdline": "/usr/bin/kaccess", "instances": 1, "pid": 2130, "uid": 1000, "watches": 1 }, { "cmdline": "/usr/bin/plasmashell", "instances": 4, "pid": 2132, "uid": 1000, "watches": 20 }, { "cmdline": "/usr/lib/x86_64-linux-gnu/libexec/kactivitymanagerd", "instances": 2, "pid": 2144, "uid": 1000, "watches": 5 }, { "cmdline": "/usr/lib/x86_64-linux-gnu/libexec/DiscoverNotifier", "instances": 3, "pid": 2153, "uid": 1000, "watches": 3 }, { "cmdline": "/usr/lib/x86_64-linux-gnu/libexec/kdeconnectd", "instances": 4, "pid": 2155, "uid": 1000, "watches": 5 }, { "cmdline": "/usr/bin/gmenudbusmenuproxy", "instances": 2, "pid": 2158, "uid": 1000, "watches": 1 }, { "cmdline": "/usr/lib/x86_64-linux-gnu/libexec/kf5/kscreen_backend_launcher", "instances": 1, "pid": 2293, "uid": 1000, "watches": 1 }, { "cmdline": "/home/ade/.dropbox-dist/dropbox-lnx.x86_64-171.4.6182/dropbox", "instances": 2, "pid": 2319, "uid": 1000, "watches": 126 }, { "cmdline": "/usr/bin/python3", "instances": 3, "pid": 2361, "uid": 1000, "watches": 9 }, { "cmdline": "/usr/bin/python3", "instances": 1, "pid": 2375, "uid": 1000, "watches": 3 }, { "cmdline": "/usr/libexec/gvfs-udisks2-volume-monitor", "instances": 1, "pid": 2507, "uid": 1000, "watches": 1 }, { "cmdline": "/usr/libexec/gvfs-afc-volume-monitor", "instances": 1, "pid": 2531, "uid": 1000, "watches": 1 }, { "cmdline": "/usr/libexec/gvfsd-trash", "instances": 1, "pid": 2551, "uid": 1000, "watches": 44 }, { "cmdline": "/usr/lib/insync/insync", "instances": 4, "pid": 2570, "uid": 1000, "watches": 161 }, { "cmdline": "/lib/x86_64-linux-gnu/libexec/kf5/kioslave5", "instances": 1, "pid": 2584, "uid": 1000, "watches": 1 }, { "cmdline": "/usr/bin/dolphin", "instances": 5, "pid": 2930, "uid": 1000, "watches": 13 }, { "cmdline": "/bin/bash", "instances": 2, "pid": 2945, "uid": 1000, "watches": 2 }, { "cmdline": "/lib/x86_64-linux-gnu/libexec/kf5/kioslave5", "instances": 4, "pid": 18463, "uid": 1000, "watches": 3 }, { "cmdline": "/lib/x86_64-linux-gnu/libexec/kf5/kioslave5", "instances": 4, "pid": 18566, "uid": 1000, "watches": 5 }, { "cmdline": "/lib/x86_64-linux-gnu/libexec/kf5/kioslave5", "instances": 5, "pid": 18589, "uid": 1000, "watches": 5 }, { "cmdline": "kde-inotify-survey", "instances": 2, "pid": 18690, "uid": 1000, "watches": 2 } ], "totals": { "instancePercent": 33, "instances": 86, "maxInstances": 256, "maxWatches": 1048576, "watchPercent": 2, "watches": 21853 } }
(In reply to adec2011.ac from comment #19) > (In reply to Méven Car from comment #17) > > I don't reproduce this in Dolphin 22.12. > > > > Can anyone still reproduce it ? > > It is still happening for me. > > In an open dolphin windows I have a wastebin icon under the places list. > WHen i right click and select empty wastebin the bin doesnt empty and the > icon doesnt change unless i physically click the icon to open it in the > dolphin window and refresh the contents > I wasn't using the places panel context menu to empty the trash. With this method, I don't reproduce either with dolpin 22.12 or 23.08 (dev). Maybe there is more to it. Does it happen for files and folders ? any file sizes ? On any of your disk drives if you are using multiple ones ? Can you think of something particular in your situation ?
It happens with any files or folders from any drive. If i right click the places wastebin and select empty trash the action will not automatically empty the trash only when i left click on the same wastebin icon in places to open the wastebin folder in the dolphin window (after selecting empty trash with right click originally) and keep left pressing the icon in places will the trash refresh and the icon changes to an empty icon
I have just seen this bug with a small .jpg file sent to Trash from /Home/Download/subfolder. Operating System: Arch Linux KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 Graphics Platform: Wayland
*** Bug 472978 has been marked as a duplicate of this bug. ***
*** Bug 482852 has been marked as a duplicate of this bug. ***
Marking confirmed since the same behavior was reported in other issues
Which desktop layout are using desktop or folder view ? You have folder view if you have icons of your wallpaper/desktop. Simply put, do you have icons on your desktop ? Does opening `desktop:/` in dolphin change the behavior ? A component watching for trash updates, is not started if you use the "desktop" layout and might explain why I don't reproduce this. Haven't checked myself. https://invent.kde.org/plasma/plasma-workspace/-/blob/master/kioworkers/desktop/desktopnotifier.cpp Another to check is to launch `kcmshell6 kcm_kded` and whether or not "Directory Watcher" is launched/running.
(In reply to Méven Car from comment #30) > Which desktop layout are using desktop or folder view ? > You have folder view if you have icons of your wallpaper/desktop. > > Simply put, do you have icons on your desktop ? > Does opening `desktop:/` in dolphin change the behavior ? > > A component watching for trash updates, is not started if you use the > "desktop" layout and might explain why I don't reproduce this. > Haven't checked myself. > https://invent.kde.org/plasma/plasma-workspace/-/blob/master/kioworkers/ > desktop/desktopnotifier.cpp > > Another to check is to launch `kcmshell6 kcm_kded` and whether or not > "Directory Watcher" is launched/running. Why should folder or desktop view affect the behaviour of a file manager's ability to monitor its own trash? A file manager should be entirely independant of a user's desktop settings.
(In reply to Pete from comment #31) > (In reply to Méven Car from comment #30) > > Which desktop layout are using desktop or folder view ? > > You have folder view if you have icons of your wallpaper/desktop. > > > > Simply put, do you have icons on your desktop ? > > Does opening `desktop:/` in dolphin change the behavior ? > > > > A component watching for trash updates, is not started if you use the > > "desktop" layout and might explain why I don't reproduce this. > > Haven't checked myself. > > https://invent.kde.org/plasma/plasma-workspace/-/blob/master/kioworkers/ > > desktop/desktopnotifier.cpp > > > > Another to check is to launch `kcmshell6 kcm_kded` and whether or not > > "Directory Watcher" is launched/running. > > Why should folder or desktop view affect the behaviour of a file manager's > ability to monitor its own trash? Because dolphin is mostly tested/used in plasma with default settings, this hasn't been noticed. KDE code spans decades, that we inherit as-is by from previous maintainers, that had limited resources as do we always. Code evolves organically often without overarching design, this is especially true for old components such as trash:/. > A file manager should be entirely independant of a user's desktop settings. You are correct dolphin shouldn't depend on this, not primarly for design but for not-plasma users of dolphin. Fixing this might be a fix for this bug. But please answer to my questions so I actually _know_ that's the issue. That would be more valuable to fix the bug than having to explain the past.
(In reply to Méven Car from comment #32) > (In reply to Pete from comment #31) > > (In reply to Méven Car from comment #30) > > > Which desktop layout are using desktop or folder view ? > > > You have folder view if you have icons of your wallpaper/desktop. > > > > > > Simply put, do you have icons on your desktop ? > > > Does opening `desktop:/` in dolphin change the behavior ? > > > > > > A component watching for trash updates, is not started if you use the > > > "desktop" layout and might explain why I don't reproduce this. > > > Haven't checked myself. > > > https://invent.kde.org/plasma/plasma-workspace/-/blob/master/kioworkers/ > > > desktop/desktopnotifier.cpp > > > > > > Another to check is to launch `kcmshell6 kcm_kded` and whether or not > > > "Directory Watcher" is launched/running. > > > > Why should folder or desktop view affect the behaviour of a file manager's > > ability to monitor its own trash? > > Because dolphin is mostly tested/used in plasma with default settings, this > hasn't been noticed. > > KDE code spans decades, that we inherit as-is by from previous maintainers, > that had limited resources as do we always. > Code evolves organically often without overarching design, this is > especially true for old components such as trash:/. > > > A file manager should be entirely independant of a user's desktop settings. > > You are correct dolphin shouldn't depend on this, not primarly for design > but for not-plasma users of dolphin. Fixing this might be a fix for this bug. > > But please answer to my questions so I actually _know_ that's the issue. > That would be more valuable to fix the bug than having to explain the past. Understood. But I just tested Dolphin in both folder and desktop view and the results are the same for both. Emtpy trash continues to show contents until refreshed manually.
(In reply to Pete from comment #33) > (In reply to Méven Car from comment #32) > > (In reply to Pete from comment #31) > > > (In reply to Méven Car from comment #30) > > > > Which desktop layout are using desktop or folder view ? > > > > You have folder view if you have icons of your wallpaper/desktop. > > > > > > > > Simply put, do you have icons on your desktop ? > > > > Does opening `desktop:/` in dolphin change the behavior ? > > > > > > > > A component watching for trash updates, is not started if you use the > > > > "desktop" layout and might explain why I don't reproduce this. > > > > Haven't checked myself. > > > > https://invent.kde.org/plasma/plasma-workspace/-/blob/master/kioworkers/ > > > > desktop/desktopnotifier.cpp > > > > > > > > Another to check is to launch `kcmshell6 kcm_kded` and whether or not > > > > "Directory Watcher" is launched/running. > > > > > > Why should folder or desktop view affect the behaviour of a file manager's > > > ability to monitor its own trash? > > > > Because dolphin is mostly tested/used in plasma with default settings, this > > hasn't been noticed. > > > > KDE code spans decades, that we inherit as-is by from previous maintainers, > > that had limited resources as do we always. > > Code evolves organically often without overarching design, this is > > especially true for old components such as trash:/. > > > > > A file manager should be entirely independant of a user's desktop settings. > > > > You are correct dolphin shouldn't depend on this, not primarly for design > > but for not-plasma users of dolphin. Fixing this might be a fix for this bug. > > > > But please answer to my questions so I actually _know_ that's the issue. > > That would be more valuable to fix the bug than having to explain the past. > > Understood. But I just tested Dolphin in both folder and desktop view and > the results are the same for both. Emtpy trash continues to show contents > until refreshed manually. I should have added you need to logout for the desktop view change to have an effect. You can use, to otherwise check: > Another to check is to launch `kcmshell6 kcm_kded` and whether or not > "Directory Watcher" is launched/running. If my hypothesis is correct: If it is running the bug would not happen, if it is not running the bug would be present.
(In reply to Méven Car from comment #34) > (In reply to Pete from comment #33) > > (In reply to Méven Car from comment #32) > > > (In reply to Pete from comment #31) > > > > (In reply to Méven Car from comment #30) > > > > > Which desktop layout are using desktop or folder view ? > > > > > You have folder view if you have icons of your wallpaper/desktop. > > > > > > > > > > Simply put, do you have icons on your desktop ? > > > > > Does opening `desktop:/` in dolphin change the behavior ? > > > > > > > > > > A component watching for trash updates, is not started if you use the > > > > > "desktop" layout and might explain why I don't reproduce this. > > > > > Haven't checked myself. > > > > > https://invent.kde.org/plasma/plasma-workspace/-/blob/master/kioworkers/ > > > > > desktop/desktopnotifier.cpp > > > > > > > > > > Another to check is to launch `kcmshell6 kcm_kded` and whether or not > > > > > "Directory Watcher" is launched/running. > > > > > > > > Why should folder or desktop view affect the behaviour of a file manager's > > > > ability to monitor its own trash? > > > > > > Because dolphin is mostly tested/used in plasma with default settings, this > > > hasn't been noticed. > > > > > > KDE code spans decades, that we inherit as-is by from previous maintainers, > > > that had limited resources as do we always. > > > Code evolves organically often without overarching design, this is > > > especially true for old components such as trash:/. > > > > > > > A file manager should be entirely independant of a user's desktop settings. > > > > > > You are correct dolphin shouldn't depend on this, not primarly for design > > > but for not-plasma users of dolphin. Fixing this might be a fix for this bug. > > > > > > But please answer to my questions so I actually _know_ that's the issue. > > > That would be more valuable to fix the bug than having to explain the past. > > > > Understood. But I just tested Dolphin in both folder and desktop view and > > the results are the same for both. Emtpy trash continues to show contents > > until refreshed manually. > > I should have added you need to logout for the desktop view change to have > an effect. > > You can use, to otherwise check: > > Another to check is to launch `kcmshell6 kcm_kded` and whether or not > > "Directory Watcher" is launched/running. > > If my hypothesis is correct: > If it is running the bug would not happen, if it is not running the bug > would be present. Am pretty sure its running, Screenshot of my background services: https://imgur.com/a/hPCX0rA
(In reply to Pete from comment #35) > (In reply to Méven Car from comment #34) > > (In reply to Pete from comment #33) > > > (In reply to Méven Car from comment #32) > > > > (In reply to Pete from comment #31) > > > > > (In reply to Méven Car from comment #30) > > > > > > Which desktop layout are using desktop or folder view ? > > > > > > You have folder view if you have icons of your wallpaper/desktop. > > > > > > > > > > > > Simply put, do you have icons on your desktop ? > > > > > > Does opening `desktop:/` in dolphin change the behavior ? > > > > > > > > > > > > A component watching for trash updates, is not started if you use the > > > > > > "desktop" layout and might explain why I don't reproduce this. > > > > > > Haven't checked myself. > > > > > > https://invent.kde.org/plasma/plasma-workspace/-/blob/master/kioworkers/ > > > > > > desktop/desktopnotifier.cpp > > > > > > > > > > > > Another to check is to launch `kcmshell6 kcm_kded` and whether or not > > > > > > "Directory Watcher" is launched/running. > > > > > > > > > > Why should folder or desktop view affect the behaviour of a file manager's > > > > > ability to monitor its own trash? > > > > > > > > Because dolphin is mostly tested/used in plasma with default settings, this > > > > hasn't been noticed. > > > > > > > > KDE code spans decades, that we inherit as-is by from previous maintainers, > > > > that had limited resources as do we always. > > > > Code evolves organically often without overarching design, this is > > > > especially true for old components such as trash:/. > > > > > > > > > A file manager should be entirely independant of a user's desktop settings. > > > > > > > > You are correct dolphin shouldn't depend on this, not primarly for design > > > > but for not-plasma users of dolphin. Fixing this might be a fix for this bug. > > > > > > > > But please answer to my questions so I actually _know_ that's the issue. > > > > That would be more valuable to fix the bug than having to explain the past. > > > > > > Understood. But I just tested Dolphin in both folder and desktop view and > > > the results are the same for both. Emtpy trash continues to show contents > > > until refreshed manually. > > > > I should have added you need to logout for the desktop view change to have > > an effect. > > > > You can use, to otherwise check: > > > Another to check is to launch `kcmshell6 kcm_kded` and whether or not > > > "Directory Watcher" is launched/running. > > > > If my hypothesis is correct: > > If it is running the bug would not happen, if it is not running the bug > > would be present. > > Am pretty sure its running, Screenshot of my background services: > > https://imgur.com/a/hPCX0rA You need to filter at the top right for launched ones.
The bug hasn't been affecting me for quite some time now. I didn't change anything other than the regular system updates. Operating System: Manjaro Linux KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.5.0 Qt Version: 6.7.2
(In reply to Méven Car from comment #36) > (In reply to Pete from comment #35) > > (In reply to Méven Car from comment #34) > > > (In reply to Pete from comment #33) > > > > (In reply to Méven Car from comment #32) > > > > > (In reply to Pete from comment #31) > > > > > > (In reply to Méven Car from comment #30) > > > > > > > Which desktop layout are using desktop or folder view ? > > > > > > > You have folder view if you have icons of your wallpaper/desktop. > > > > > > > > > > > > > > Simply put, do you have icons on your desktop ? > > > > > > > Does opening `desktop:/` in dolphin change the behavior ? > > > > > > > > > > > > > > A component watching for trash updates, is not started if you use the > > > > > > > "desktop" layout and might explain why I don't reproduce this. > > > > > > > Haven't checked myself. > > > > > > > https://invent.kde.org/plasma/plasma-workspace/-/blob/master/kioworkers/ > > > > > > > desktop/desktopnotifier.cpp > > > > > > > > > > > > > > Another to check is to launch `kcmshell6 kcm_kded` and whether or not > > > > > > > "Directory Watcher" is launched/running. > > > > > > > > > > > > Why should folder or desktop view affect the behaviour of a file manager's > > > > > > ability to monitor its own trash? > > > > > > > > > > Because dolphin is mostly tested/used in plasma with default settings, this > > > > > hasn't been noticed. > > > > > > > > > > KDE code spans decades, that we inherit as-is by from previous maintainers, > > > > > that had limited resources as do we always. > > > > > Code evolves organically often without overarching design, this is > > > > > especially true for old components such as trash:/. > > > > > > > > > > > A file manager should be entirely independant of a user's desktop settings. > > > > > > > > > > You are correct dolphin shouldn't depend on this, not primarly for design > > > > > but for not-plasma users of dolphin. Fixing this might be a fix for this bug. > > > > > > > > > > But please answer to my questions so I actually _know_ that's the issue. > > > > > That would be more valuable to fix the bug than having to explain the past. > > > > > > > > Understood. But I just tested Dolphin in both folder and desktop view and > > > > the results are the same for both. Emtpy trash continues to show contents > > > > until refreshed manually. > > > > > > I should have added you need to logout for the desktop view change to have > > > an effect. > > > > > > You can use, to otherwise check: > > > > Another to check is to launch `kcmshell6 kcm_kded` and whether or not > > > > "Directory Watcher" is launched/running. > > > > > > If my hypothesis is correct: > > > If it is running the bug would not happen, if it is not running the bug > > > would be present. > > > > Am pretty sure its running, Screenshot of my background services: > > > > https://imgur.com/a/hPCX0rA > > You need to filter at the top right for launched ones. Sorry about that. Filtered it and Directory Watcher is running. Seems others aren't having this issue anymore just me which is weird. Operating System: Arch Linux KDE Plasma Version: 6.1.5 KDE Frameworks Version: 6.6.0 Qt Version: 6.7.2 Kernel Version: 6.10.9-arch1-2 (64-bit) Graphics Platform: Wayland
(In reply to Pete from comment #38) > (In reply to Méven Car from comment #36) > > (In reply to Pete from comment #35) > > > (In reply to Méven Car from comment #34) > > > > (In reply to Pete from comment #33) > > > > > (In reply to Méven Car from comment #32) > > > > > > (In reply to Pete from comment #31) > > > > > > > (In reply to Méven Car from comment #30) > > > > > > > > Which desktop layout are using desktop or folder view ? > > > > > > > > You have folder view if you have icons of your wallpaper/desktop. > > > > > > > > > > > > > > > > Simply put, do you have icons on your desktop ? > > > > > > > > Does opening `desktop:/` in dolphin change the behavior ? > > > > > > > > > > > > > > > > A component watching for trash updates, is not started if you use the > > > > > > > > "desktop" layout and might explain why I don't reproduce this. > > > > > > > > Haven't checked myself. > > > > > > > > https://invent.kde.org/plasma/plasma-workspace/-/blob/master/kioworkers/ > > > > > > > > desktop/desktopnotifier.cpp > > > > > > > > > > > > > > > > Another to check is to launch `kcmshell6 kcm_kded` and whether or not > > > > > > > > "Directory Watcher" is launched/running. > > > > > > > > > > > > > > Why should folder or desktop view affect the behaviour of a file manager's > > > > > > > ability to monitor its own trash? > > > > > > > > > > > > Because dolphin is mostly tested/used in plasma with default settings, this > > > > > > hasn't been noticed. > > > > > > > > > > > > KDE code spans decades, that we inherit as-is by from previous maintainers, > > > > > > that had limited resources as do we always. > > > > > > Code evolves organically often without overarching design, this is > > > > > > especially true for old components such as trash:/. > > > > > > > > > > > > > A file manager should be entirely independant of a user's desktop settings. > > > > > > > > > > > > You are correct dolphin shouldn't depend on this, not primarly for design > > > > > > but for not-plasma users of dolphin. Fixing this might be a fix for this bug. > > > > > > > > > > > > But please answer to my questions so I actually _know_ that's the issue. > > > > > > That would be more valuable to fix the bug than having to explain the past. > > > > > > > > > > Understood. But I just tested Dolphin in both folder and desktop view and > > > > > the results are the same for both. Emtpy trash continues to show contents > > > > > until refreshed manually. > > > > > > > > I should have added you need to logout for the desktop view change to have > > > > an effect. > > > > > > > > You can use, to otherwise check: > > > > > Another to check is to launch `kcmshell6 kcm_kded` and whether or not > > > > > "Directory Watcher" is launched/running. > > > > > > > > If my hypothesis is correct: > > > > If it is running the bug would not happen, if it is not running the bug > > > > would be present. > > > > > > Am pretty sure its running, Screenshot of my background services: > > > > > > https://imgur.com/a/hPCX0rA > > > > You need to filter at the top right for launched ones. > > Sorry about that. Filtered it and Directory Watcher is running. Seems others > aren't having this issue anymore just me which is weird. > > Operating System: Arch Linux > KDE Plasma Version: 6.1.5 > KDE Frameworks Version: 6.6.0 > Qt Version: 6.7.2 > Kernel Version: 6.10.9-arch1-2 (64-bit) > Graphics Platform: Wayland I confirmed on my side the kded not running is not sufficient to explain the bug. The far-fetched hypothesis is inotify not working (it has a limited number of watches it can handde). That would happen if you have for instance an IDE without a lot of files/folders opened, or more generally a lot of applications. Or a specific that would be buggy. Or dbus not working properly/not installed. But without dbus a lot of other things would be degraded like any notifications. Given you are using arch they are a thousand ways to shout you in the foot. How custom is your arch install ? Did you use infamous plasma-meta package by any chance ? (I am using Arch myself). Then you are missing something from the plasma group https://wiki.archlinux.org/title/KDE
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/1809
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/1811
Git commit ae12ee6df31ba70bdaee81c7f1206c826cdc3924 by Méven Car. Committed on 03/02/2025 at 12:25. Pushed by meven into branch 'master'. trashimpl: reparse trashrc in fileRemoved The file on disk may have been edited by another instance of trash Worker, the m_config state would then be out of date consequently a next writeEntry() and sync() may not save the config to disk. Similar to the fix of 167388. M +3 -0 src/kioworkers/trash/trashimpl.cpp https://invent.kde.org/frameworks/kio/-/commit/ae12ee6df31ba70bdaee81c7f1206c826cdc3924