The devices list still list deleted Loop Devices. How to reproduce: dd if=/dev/zero of=test.dd bs=1M count=1 sudo losetup --find --show /home/devent/test.dd Dolphin now shows "Loop Device" in "Devices". sudo losetup -d /dev/loop0 sudo losetup -a No loop devices found. But Dolphin still shows "Loop Device" in "Devices".
Thanks for the report. I think that this is most likely a Solid issue (this is the library that tells us about the available devices).
*** Bug 320573 has been marked as a duplicate of this bug. ***
Can you reproduce the bug and execute: solid-hardware list before and after? Thanks !
Created attachment 81413 [details] Solid hardware list before and after.
Created attachment 81414 [details] Dolphin places with devices
I put the commands and output in the attached text file. KDE 4.10.4 Dolphin 2.2
In 4.11 nothing shows in dolphin, which at least given your command line is the intended behavior since dolphin can't do anything with a device without FS. Should we close this bug ?
I just observed something. When I close Dolphin and open Dolphin again then the deleted loop device is gone. That was not the case when I opened the bug report in 4.10.3. But you have to close and open Dolphin, because the already opened Dolphin windows still have the deleted loop device in Places/Devices. It's not critical bug now because you can just close and open Dolphin if there are too many invalid devices.
Does this mean the issue is in Dolphin, not reacting to Solid signals?
Created attachment 81631 [details] Dolphin window a) before creating, b) after deleting I don't know. I tested again with KDE 4.10.5, same behaviour. I attach a screen shot showing two Dolphin windows, one open before the creation of the loop device, and one opened after the deletion. Both windows should not show the deleted loop device.
(In reply to comment #9) > Does this mean the issue is in Dolphin, not reacting to Solid signals? Dolphin does listen to Solid's deviceAdded and deviceRemoved signals.
Are you using 4.11 now? if not, can you give it a try (using latest RC, for example on a livecd) ? Thanks !
I'm using 4.10. Can you please point to me how can I test 4.11 on a livecd? My search in Google was not successful.
(In reply to comment #13) > I'm using 4.10. > Can you please point to me how can I test 4.11 on a livecd? My search in > Google was not successful. Try this openSUSE livecd : http://download.opensuse.org/distribution/13.1-Milestone4/iso/openSUSE-Factory-KDE-Live-Build0652-x86_64.iso
Erwin, any progress on testing with KDE 4.11?
Hello, I tested it with OpenSuse with KDE 4.10.97 with Dolphin and I get the same behaviour like described in Comment 8 and Comment 10.
can you attach the output of udiskctl dump ? Thanks
Created attachment 82059 [details] before creating loop-device
Created attachment 82060 [details] Loop-device created, loop showing in Dolphin
Created attachment 82061 [details] Removed loop device, still showing in Dolphin Sorry, I don't see how I can attach multiple files in one post.
I still can't reproduce this :/ let's try this: look in solid-hardware list, for the device that losetup -find gave you (I 'm guessting that's the one shown in dolphin). then do solid-hardware deatils /org/freedesktop/.... And paste the output. also, if you can execute dolphin and "solid-hardware listen" in a terminal, reproduce the bug and report the output will be nice as well. Make sure to have everything containing "Dolphin" in kdebugdialgo checked. Thanks !
To further investigate this issue, KDE developers need the information requested in comment #21. If you can provide it, or need help with finding that information, please add a comment.
*** Bug 331601 has been marked as a duplicate of this bug. ***
Created attachment 85371 [details] Output requested in comment #21 (In reply to comment #21) > look in solid-hardware list, for the device that losetup -find gave you (I > 'm guessting that's the one shown in dolphin). > > then do > solid-hardware deatils /org/freedesktop/.... > > And paste the output. > > also, if you can execute dolphin and "solid-hardware listen" in a terminal, > reproduce the bug and report the output will be nice as well. See attachment. > Make sure to have everything containing "Dolphin" in kdebugdialgo checked. > I'm not sure what that means.
Alex, does comment #24 provide the requested information? Please set the bug status.
No response, changing status.
Duplicate: https://bugs.kde.org/show_bug.cgi?id=369434
*** Bug 369434 has been marked as a duplicate of this bug. ***
Git commit 1384f275ab2f1ad1841753ee163af6d1b0bb952b by Kai Uwe Broulik. Committed on 23/01/2018 at 16:06. Pushed by broulik into branch 'master'. [UDisks] Ignore non-user mounts This gets rid of all those internal mounts, such as /snap mounts. The approach is similar to GVFS which ignores everything outside /media, /home/user, and /media/run, cf. https://github.com/GNOME/gvfs/blob/master/monitor/udisks2/what-is-shown.txt Explicitly creating a mount in /etc/fstab outside of those directories is still possible and will always show up. Related: bug 379516 CHANGELOG: Storage devices mounted outside of /media, /run/media, and $HOME are now ignored, as well as Loop Devices whose backing file is outside of $HOME Differential Revision: https://phabricator.kde.org/D9895 M +10 -1 src/solid/devices/backends/udisks2/udisksstorageaccess.cpp M +13 -2 src/solid/devices/backends/udisks2/udisksstoragevolume.cpp https://commits.kde.org/solid/1384f275ab2f1ad1841753ee163af6d1b0bb952b
I wish what the desktop environments do now didn't look so ad hoc. :) The issue of filesystems staying in the places list (and AFAICT, plasmashell slowing down) is not fixed by this, there are just fewer real life cases that could trigger the problem. I.e. if I moved my systemd auto-mount from /usr/repos to $HOME/repos I would have to reopen this report. My expectation was that KDE is properly informed by udisks about the disappearance of the loop device even if that means opening a bug report with the kernel. I don't have a deep understanding of the issue though.
(In reply to Marco Leise from comment #30) > I wish what the desktop environments do now didn't look so ad hoc. :) > The issue of filesystems staying in the places list (and AFAICT, plasmashell > slowing down) is not fixed by this, there are just fewer real life cases > that could trigger the problem. I.e. if I moved my systemd auto-mount from > /usr/repos to $HOME/repos I would have to reopen this report. > > My expectation was that KDE is properly informed by udisks about the > disappearance of the loop device even if that means opening a bug report > with the kernel. I don't have a deep understanding of the issue though. There are two different aspects here: 1. Loop devices without backing file 2. User mounted loop devices (having a backing file) The first should never be shown. If these are, it is a bug. The second can only be handled in a heuristic way. The heuristic says when the user has mounted e.g. a iso image, it is sensible to make it accessible and findable by default. Now, it is perfectly valid to have something permanent mounted in your home directory. But if you add this *manually*, you should go the full way and tell the infrastructure it should ignore it. This is easy to do, just add an x-gvfs-ignore=true hint to your filesystem options.
(In reply to Stefan Brüns from comment #31) > > There are two different aspects here: > 1. Loop devices without backing file > 2. User mounted loop devices (having a backing file) > > The first should never be shown. If these are, it is a bug. Handling of the corresponding UDisks2 PropertiesChanged signal seems to be missing: signal time=1523212908.677989 sender=:1.57505 -> destination=(null destination) serial=10250 path=/org/freedesktop/UDisks2; interface=org.freedesktop.DBus.ObjectManager; member=InterfacesRemoved object path "/org/freedesktop/UDisks2/block_devices/loop0" array [ string "org.freedesktop.UDisks2.Filesystem" ] signal time=1523212908.678019 sender=:1.57505 -> destination=(null destination) serial=10251 path=/org/freedesktop/UDisks2/block_devices/loop0; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged string "org.freedesktop.UDisks2.Block" array [ dict entry( string "IdUUID" variant string "" ) dict entry( string "IdLabel" variant string "" ) dict entry( string "IdVersion" variant string "" ) dict entry( string "IdType" variant string "" ) dict entry( string "IdUsage" variant string "" ) dict entry( string "Size" variant uint64 0 ) dict entry( string "Symlinks" variant array [ ] ) ] array [ ] signal time=1523212908.678099 sender=:1.57505 -> destination=(null destination) serial=10252 path=/org/freedesktop/UDisks2/block_devices/loop0; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged string "org.freedesktop.UDisks2.Loop" array [ dict entry( string "Autoclear" variant boolean false ) dict entry( string "BackingFile" variant array of bytes "" + \0 ) ] array [ ]
The places widget receives all necessary events, put does not deal correctly with devices changing from "accessible" to "hidden". If a device does not have a filesystem at startup (e.g. an unused loop device), it is filtered out by the solid predicates, and thus hidden. When the loop device gets used by mounting a image, it will be added. The opposite, unmounting, does not have the opposing effect.
Hello! Sorry to be the bearer of bad news, but this project has been unmaintained for many years so I am closing this bug. Please try again with the latest version and submit a new bug to frameworks-solid if your issue persists. Thank you!
@ Andrew: Who are you to decide what is maintained and what not? Look at the git log. And stop anoying developers and wasting their time by adding useless noise.
So is this still an issue? If so, it should be re-opened. I've moved the status back to RESOLVED so now anyone can.
(In reply to Nate Graham from comment #36) > So is this still an issue? If so, it should be re-opened. I've moved the > status back to RESOLVED so now anyone can. My auto-mount device in /usr/repos is no longer showing up in Dolphin. This part is working now! I have not tried auto-mounts in $HOME or any of the other cases listed here.
I don't see any issues with loop devices with the latest versions anymore. Thanks everyone.