Re: Automounting GVFS systems when devices are added?
- From: David Zeuthen <david fubar dk>
- To: Patrick Walton <pcwalton ucla edu>
- Cc: gvfs-list gnome org
- Subject: Re: Automounting GVFS systems when devices are added?
- Date: Mon, 13 Oct 2008 20:22:01 -0400
On Mon, 2008-10-13 at 14:47 -0700, Patrick Walton wrote:
> > Actually you really want a separate volume monitor [1], see the gphoto2
> > volume monitor (monitor/gphoto2 in the gvfs tree) for details on how to
> > write one; it should be straightforward [3].
>
> This is what I was thinking of. It should still use HAL for device
> detection for the time being though, right?
Yeah. At some point we want to move this stuff to DeviceKit but more
about that later.
> So what I'm thinking about doing is adding a new value for volume.fstype
> in HAL, "afc".
Oh, volume.fstype is a well-defined property that only makes sense for
block devices; it doesn't make sense to overload it here. I'd introduce
a new capability 'afc' and use the afc.* namespace for properties you
need, e.g. "bool afc.secondary_volume_support" (not a good idea to use
names like jail or broken etc.)
> When my "gvfsmonitord-afc" or whatever sees a device that
> supports afc, it'll mount the volume. If the phone is jailbroken, it
> should mount both the jailed and jailbroken volumes (the convention is
> for the jailbroken volume to be accessible at com.apple.afc2).
If by "mount the volume" you mean "create a GVolume object with an
activation root that leads to mounting the device" then, yeah, that's
the way to do it. It should look pretty much like the gphoto2 volume
monitor.
(Nautilus takes care of the automounting depending on the result of
g_volume_should_automount()...).
Do you use the same USB interface (e.g. same endpoints) for accessing
the jailbroken volume as well as the jailed volume? If so, the same
mount need to serve both the jailbroken and jailed volume (USB only
supports single opener).... There's some complications here on how to
handle it in the event you want two GVolume objects; I'll elaborate if
it's that's the case (the shadow mounts stuff will come in handy here).
Btw, how does this work with PTP stuff? Can your backend co-exist with
the gphoto2 gvfs backend, e.g. does AFC stuff use another interface as
that of PTP?
And since I'm an iPhone owner myself I'm curious - what stuff will be
available on the jailed resp. jailbroken volumes?
> Oh, and it doesn't support multiple iPhones or iPods at the moment,
> because the underlying libiphone doesn't support them. However, I agree
> that the URI should be in a form that allows us to support multiple
> devices in the future. What would really be best is to use the serial
> number of the device as an identifier (so, say,
> afc://YM2105825234:com.apple.afc/), I think. This is an important
> property to expose to applications anyway, because it is needed in the
> obfuscated signature for the music database.
I think it's more logical to use the same scheme as the gphoto2 backend,
e.g. afc://[usb:001,002] with bus and device number. The serial number
should probably be exported through both G_VOLUME_IDENTIFIER_KIND_UUID
and g_mount_get_uuid() [1].
David.
[1] : we need fix GDaemonMount to actually take this from the backend
but that shouldn't be hard.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]