GNOME Bugzilla – Bug 573826
gdu volume monitor
Last modified: 2009-05-01 22:35:13 UTC
This is a bug for tracking the gnome-disk-utility volume monitor, see http://mail.gnome.org/archives/gvfs-list/2009-March/msg00002.html for details. I'll try to update this bug when updating the patch.
Created attachment 129894 [details] [review] patch This patch is almost like the one I posted to the mailing list. The only difference is that it stays quiet when the DeviceKit-disks daemon is inhibited [1] [1] : See http://cgit.freedesktop.org/DeviceKit/DeviceKit-disks/commit/?id=65999009bb026972526c756aa62bf0486318ebfe for details on why this is useful $ diffstat gvfs-gdu-volume-monitor-2.patch configure.ac | 29 monitor/Makefile.am | 4 monitor/gdu/Makefile.am | 53 monitor/gdu/gdu-volume-monitor-daemon.c | 46 monitor/gdu/gdu.monitor | 5 monitor/gdu/ggdudrive.c | 691 +++++++ monitor/gdu/ggdudrive.h | 69 monitor/gdu/ggdumount.c | 958 ++++++++++ monitor/gdu/ggdumount.h | 64 monitor/gdu/ggduvolume.c | 1408 +++++++++++++++ monitor/gdu/ggduvolume.h | 78 monitor/gdu/ggduvolumemonitor.c | 1432 ++++++++++++++++ monitor/gdu/ggduvolumemonitor.h | 60 monitor/gdu/org.gtk.Private.GduVolumeMonitor.service.in | 3 monitor/gdu/polkit.c | 137 + monitor/gdu/polkit.h | 44 16 files changed, 5080 insertions(+), 1 deletion(-)
Created attachment 130070 [details] [review] updated patch Updated patch that fixes https://bugzilla.redhat.com/show_bug.cgi?id=488399
Created attachment 130197 [details] [review] gvfs-1.1.7-gdu-monitor-empty-drives.patch Apply on top of gvfs-gdu-volume-monitor-3.patch This fixes a typo - wrong assignment of device file when testing whether the volume should be ignored or not. It led to empty GVolume list associated to a GDrive and thus inability to mount anything via computer://
(In reply to comment #3) > Created an attachment (id=130197) [edit] > gvfs-1.1.7-gdu-monitor-empty-drives.patch > > Apply on top of gvfs-gdu-volume-monitor-3.patch > > This fixes a typo - wrong assignment of device file when testing whether the > volume should be ignored or not. It led to empty GVolume list associated to a > GDrive and thus inability to mount anything via computer:// > Nice catch. Looks good to me after taking a cursory look. Can (I'm a bit surprised that the compiler doesn't bitch about the device_file variable being shadowed.)
Created attachment 130338 [details] [review] gvfs-1.1.7-gdu-computer-expose-devices.patch This patch will expose the device file string (i.e. /dev/sda2) for items in computer://. This is then used in nautilus-gdu to get selected device. I've introduced new G_FILE_ATTRIBUTE_MOUNTABLE_UNIX_DEVICE_FILE attribute, glib patch follows.
Created attachment 130339 [details] [review] glib patch adding the G_FILE_ATTRIBUTE_MOUNTABLE_UNIX_DEVICE_FILE attribute
(In reply to comment #5) > Created an attachment (id=130338) [edit] > gvfs-1.1.7-gdu-computer-expose-devices.patch > > This patch will expose the device file string (i.e. /dev/sda2) for items in > computer://. This is then used in nautilus-gdu to get selected device. > > I've introduced new G_FILE_ATTRIBUTE_MOUNTABLE_UNIX_DEVICE_FILE attribute, glib > patch follows. > Not sure we need to add new API here [1] but it probably wouldn't hurt... [1] : ok so it's a tad complicated: get the GMount for the GFile, then the GVolume and then get the device file via G_VOLUME_IDENTIFIER_KIND_UNIX_DEVICE
Created attachment 132421 [details] [review] avoid mounting stuff from virtual or unknown buses https://bugzilla.redhat.com/show_bug.cgi?id=494144 points out that automounting device-mapper devices is unfortunate. There's a note that we may want to automount a) more concrete device-mapper users like LVM2; and b) Linux Software RAID; in the future. Right now this is moot as we have no good autoassembly story for such multi-disk constructs. This patch goes on top of the others.
And, eh, ignore the debug spew. I'll remove that when merging this into git master.
Just for the record, I'm now keeping track of these patches in this git repo http://cgit.freedesktop.org/~david/gvfs/log/?h=gdu-volume-monitor When GVfs switches to git and master becomes 2.27.* we can merge this.
(In reply to comment #7) > Not sure we need to add new API here [1] but it probably wouldn't hurt... > > [1] : ok so it's a tad complicated: get the GMount for the GFile, then the > GVolume and then get the device file via G_VOLUME_IDENTIFIER_KIND_UNIX_DEVICE Not sure I follow your thoughts fully... the computer backend exposes nothing more than the volume name and icon, no way to get GVolume or GDrive objects. GMount is not applicable here as we need to cover the use case with unmounted volumes.
(In reply to comment #11) > (In reply to comment #7) > > Not sure we need to add new API here [1] but it probably wouldn't hurt... > > > > [1] : ok so it's a tad complicated: get the GMount for the GFile, then the > > GVolume and then get the device file via G_VOLUME_IDENTIFIER_KIND_UNIX_DEVICE > > Not sure I follow your thoughts fully... the computer backend exposes nothing > more than the volume name and icon, no way to get GVolume or GDrive objects. > GMount is not applicable here as we need to cover the use case with unmounted > volumes. Hmm, I guess you are right. Although note we already have mountable::unix-device that does this http://library.gnome.org/devel/gio/unstable/GFileInfo.html#G-FILE-ATTRIBUTE-MOUNTABLE-UNIX-DEVICE--CAPS and it's normally better to look up devices using a dev_t that (some) device file name. But I guess it's convenient for apps to actually get the name of a device file they can use e.g. for open(2) and stuff (will normally result in EPERM though). So, yeah if alexl and mclasen is cool with this, let's just add that.
So, we're branched now, can we land this on master please?
Sorry, I had to roll some gnome-disk-utility and DeviceKit-disks release. I've pushed it to master now.