Re: gphoto2 backend fixes

[David Zeuthen <david fubar dk>]

On Thu, 2009-02-12 at 17:07 +0000, Bastien Nocera wrote:
> On Tue, 2009-02-10 at 14:45 -0500, David Zeuthen wrote:
> > Hey,
> > 
> > Here's a patch that fixes a couple of problems with gphoto2 devices
> > 
> >  - The support for multiple storage heads broke some buggy devices (such
> >    as the iPhone) for which the basedir of the storage head changes
> >    every time the device is initialized.
> 
> I'd rather we special-cased those devices with only one storage head in
> the gphoto2 monitor, and passed a "gphoto2://[usb:1,1,1]/store_XXXXXX"
> URI as the top-level (instead of the exact store name).

It's much harder to do it that way, you'd need to translate names in
both directions. What's wrong with this approach?

> >  - There was a silly logical bug that prevented us from detecting music
> >    players reported by HAL.
> 
> I don't think that's a logical bug. In 1.0, we disabled auto-mounting of
> music players as it would break applications that used libmtp.

Sigh. We ALREADY had this discussion a year ago for f-spot and we gave
apps a six months to catch up. Check the archives. I don't want to have
that discussion again. And I don't see why music players are different
from cameras here.

So right now applications need to do the same tricks as f-spot and
others are doing to cope with this. Which includes unmounting the GMount
from an autorun wrapper (use --unmount-scheme) or manually unmount the
GMount from application code (better). Or, you know, actually use GIO to
access the device instead of claiming it just for your own use (best).

Longer term we want some way to cope with the general case of
claiming/releasing devices; there's a ton of ways to do this but only
few ways to do it right. I haven't gotten to figuring what the best
approach here and no-one else really cares about solving it. They just
want to cripple the general IO framework in GNOME instead.

</rant>

> >  - Minor cleanups in the gphoto2 volume monitor.
> > 
> > The next item on my list is to make the rest of the desktop handles
> > shadowed mounts. There are two ways to fix this
> 
> The patch you posted gives me 3 mounts in nautilus, one top-level daemon
> one, and one for each storage head.

That's expected behavior with Nautilus HEAD. So my patch works. Thanks
for testing.

> One problem that I can see is that we can still go up from the root of
> the shadow mounts, so gphoto2://[usb:1,1,1]/store_XXXXX has a parent,
> which it shouldn't have.
> 
> I was under the impression that nautilus already knew about shadow
> mounts...

No, but see the patch I posted to Nautilus list.

    David