Re: Fixing gvfs-backend-afc for iPhone/iPod Touch access

["Martin S." <info sukimashita com>]

On Thu, 2009-07-30 at 14:45 +0100, Bastien Nocera wrote:
> On Thu, 2009-07-30 at 11:32 퍭㐱ꫭ詴낮譞:
> > Hi all,
> > 
> > As talked about briefly with David Zeuthen on IRC, I'll try to announce
> > a new backend for GVFS in order to get some help making it work and
> > allow User Joe to plug'n'play his devices.
> > 
> > It is a backend using libiphone to communicate with iPhone/iPod Touch
> > devices using the AFC protocol in a native way and allow filesystem
> > access to those.
> > 
> > It uses the afc://uuid:port/ scheme (uuid is a unique device id, port is
> > used to spawn a different afc service on the device and allow root
> > filesystem access on jailbroken devices).
> 
> How does one discover a UUID? Why can't the same scheme as before be
> used (it's been hashed to death on this list)?

You can discover the UUIDs of the connected devices using the tool
"iphone_id -l". It is provided if you installed libiphone. Handy enough,
the UUID is also the USB serial of the device.

The scheme has been "hashed to death" on this list with the basic
understanding that using a serial to access a device is the best option
of all, just libiphone was not even aware to handle multiple devices
even if you supplied the right usb:devnum combination and was in
"development hell" back at that time.

However, since then libiphone has had a major restructuring and got rid
of using usb:devnum accessors and everything is now selected by UUIDs.

The reason for this goes down to a new usbmuxd daemon which handles all
things USB wich are hidden away for libiphone. The whole libiphone API
is now based to work on UUIDs, including all provided cli tools
(iphoneinfo, iphonesyslog, iphone_id).

For the user this does not matter since we want to provide automounting
and already give the devices nice names iTunes had set (e.g.: "John
Doe's iPhone", blogged about it here
http://blog.sukimashita.com/2009/06/24/its-coming-apples-on-linux/ .

Also it is way more handy since plugging in the device to a different
USB slot would break any bookmarks and references while the serial
scheme does not. It will be unique for a device.

> 
> <snip>
> > David proposed including it in the main GVFS tree with a conditional
> > build.
> > 
> > The source code can be found here:
> > http://cgit.sukimashita.com/gvfs-backend-afc.git/
> > 
> > I am aware that the attempt at this backend is probably not perfect as
> > the main goal was to quickly have a very very basic thing working with
> > proper automounting to replace a HAL fdi "fake" mount method we use now
> > along with a fuse fs driver (and be able to close our last bug for a 1.0
> > libiphone release).
> > 
> > However writing a GVFS backend without documentation where small things
> > can hold progress back for hours because one does not know how the whole
> > system works is like a science itself and not really straightforward...
> > 
> > Thus I ask for help, especially for the volume monitor code.
> > 
> > The backend currently detects a plugged in device however one ends up
> > with:
> > - Volume (is the enclosing volume for the mount)
> >   - Mount (seems to be the mount from afc volume)
> > - Mount (as if mounted using afc://uuid/ directly)
> > 
> > The volume monitor appears to do the g_file_mount_enclosing_volume() but
> > the gvfs-backend creates another mount point.
> > 
> > As the gvfs-backend knows how to set the right display name and icons,
> > it would desired if it would create the mount but with the volume as the
> > parent.
> > 
> > When removing the device the volume monitor mount and volume is removed
> > and disappears while the backend mount is still sitting there and
> > causing issues when plugging the device back in.
> > 
> > Well, any help is appreciated also on IRC in channel #nautilus (psp250).
> 
> Could you please rebase your code to be integrated with gvfs and let me
> know where your branch is? I'll do a review, and we can push this first
> thing into gvfs 2.29 (or try to sneak it in disabled in 2.27).
> 

The gvfs-backend-afc is not a branch of GVFS anymore. I made it compile
standalone since quite a while. I'll attempt to merge/rebase the thing
ontop current GVFS but I'd also like to fix the last outstanding issue
concerning the "double backend mount+shadowproxymount" by the
volume-monitor.

--- Martin S.