Re: Enumerating hard drive volumes using GVolumeMonitor



Hey,

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
> backup).
> 
> 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
still fine.

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
   default; and

 - 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.

Thanks,
David




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]