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

[Bastien Nocera <hadess hadess net>]

On Fri, 2009-07-31 at 13:27 +0200, Martin S. wrote:
> On Fri, 2009-07-31 at 11:43 +0100, Bastien Nocera wrote:
<snip>
> > You'll be able to do that when the udev callout is added. See:
> > http://cgit.freedesktop.org/teuf/libgpod/log/?h=devicekit
> > 
> 
> Yeah, but that would make this rely on libgpod.

It would rely on a libgpod callout. Which is likely to be installed
anyway (and would do the right thing for other iPods). I don't think
that expecting it to be there (and falling back to the code that's
currently there) is much of a problem.

>  However, it might be
> really the best option to use an udev callout to set meta data for the
> iPhone/iPod Touch and then retrieve that data in both backend and
> monitor volume code effectively getting rid of all the icon/name
> determination code and keep that in one place for any consuming app
> instead.

The libgpod udev callout already does that. I don't see the point in
applications having to look in two different places for it.

> Infact, the libgpod iphone30 branch contains an updated HAL callout
> which does exactly this using libiphone...

And the devicekit branch does the same thing using udev :)

> > > Still there appears to be some read/write issues when testing sqlite3 db
> > > creation needed for music sync (probably some seek issue).
> > > Investigating...
> > 
> > I had problems writing files with the original gvfs code from Patrick,
> > but never had a chance to debug the problem...
> 
> Yeah, me aswell, actually it didn't work (backend crashed for me) and
> emulated seeking. Read/write appears to work now just that
> sqlite3_exec() appears to do something that is unhandled by the backend
> which needs fixing.

Tomas mentions that the gvfs-fuse-daemon has a debug option
(/usr/libexec//gvfs-fuse-daemon -d), and that there's a define for
DEBUG_ENABLED in gvfsfusedaemon.c.

Cheers