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



On Thu, 2009-07-30 at 16:35 +0200, Martin S. wrote:
> 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.

I seem to have missed the part where the code got rewritten, never mind.

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

I wasn't talking for the user, but yeah, seems as good a way as any
other.

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

Which is a good thing, I'm sold.

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

Don't use hal for the volume monitoring, use libgudev instead.



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