Re: Enumerating hard drive volumes using GVolumeMonitor
- From: David Zeuthen <david fubar dk>
- To: aniket ray <aniket ray gmail com>
- Cc: gvfs-list gnome org
- Subject: Re: Enumerating hard drive volumes using GVolumeMonitor
- Date: Wed, 16 Dec 2009 16:20:23 -0500
sorry for the lag - I missed your reply.
> > Care to share any details of what your app is supposed to do?
> I work on the Adobe AIR team. In our 2.0 runtime release, we have
> introduced a set of actionscript APIs that lets a user enumerate all
> user accessible mounts. Like the gio/gvfs stack, I too don't consider
> RAID components and swap potentially interesting. Normal users won't
> want to interact with it directly.
> On the other hand, I do believe that volumes (like premounted)
> harddrives and volumes that an administrator has mounted at non
> standard locations are interesting.
> End users would be interesting in knowing about that. (I still haven't
> looked at the sources for fully understanding "potentially
> interesting" on gvfs/gio.).
> In short, Applications might want to enumerate and have mount/unmount
> events on volumes that they could write on/read from.
> Hal directly provided this functionality and in our 2.0beta linux
> release, this functionality was implemented using hal.
> Hal of course, was an overly redundant behemoth and had to go. We
> would like to move to the dkd/udisks story too (maybe keeping hal as a
> Does any API / method exist off the top of your head using which I
> could enumerate the volumes ?
I think you should just use GVolumeMonitor - and here's why.
First, it would be nice if the AIR runtime would show exactly the same
thing as the users (GIO-based) desktop shell - for consistency and all.
And if it's worth showing something in AIR, it's probably worth showing
in the (GIO-based) desktop shell. And the other way around.
So if there are any problems with GVolumeMonitor not showing
user-interesting volumes we should probably fix GVolumeMonitor instead
of having applications (like AIR) supplement the list of drives/volumes.
Second, up until a couple of years ago some distros used to
create /etc/fstab entries for e.g. Windows partitions and CD-ROM drives
- often in /mnt/windows and /cdrom and similar. And these, by default,
are not shown in GIO/GVfs. It seems most stopped doing this because it's
not necessary these days - and this is a good thing because creating
such /etc/fstab entries isn't terribly dynamic - most distros hard-coded
e.g. /dev/sda2 so once you repartitioned or the boot order changed etc.
things just didn't work.
FWIW, I haven't seen any bugs in this area (and I read all GLib and GVfs
bug reports) so my guess is that what we're doing now is fine. Either
that or distros are patching GIO or GVfs to show e.g. /mnt/windows mount
points. In which case they will show up in GVolumeMonitor and we're
Anyway, on distros (such as Fedora) that don't poke around with
creating /etc/fstab entries at install time things should work out of
the box. E.g.
- mountable filesystems (from e.g. hot-plugged devices) are shown by
- if the admin wants a non-standard filesystem / devices to show up, he
can always use /etc/fstab and choose a mount point in /media or
$HOME. This is useful for e.g. NFS or FUSE mounts.
Hope this helps.
] [Thread Prev