Re: [Utopia] gnome-vfs patch, take one

[Alexander Larsson <alexl redhat com>]

On Tue, 2004-05-18 at 12:59, David Zeuthen wrote:
> Hi,
> 
> Some comments to your response; apologies for the long mail and the
> guesses and opinions stated, you might want to consider to only reply
> to the last paragraph :-)

Heh.

> > Its the only obvious problem. However, people have been hating and
> > disabling auto-mounting for as long as we've been shipping it. 
> 
> Some distributions do ship with automounting, it would be interesting
> to hear their experiences as well.

Yeah.

> > There are
> > probable other problems too. Here are some:
> > 
> > * CDROM change detection typically fails on a fair amount of hardware,
> > see all the bugs for magicdev. This requires lots of blacklisting, and
> > some way to handle mounting for the blacklisted drives.
> 
> Right, one can never avoid broken hardware or broken drivers. However,
> I'd argue (not based on anything but my common sense really, sorry)
> that it's mostly a driver issue for at least newer drives since I
> would be surprised that CDROM change detection wouldn't work on
> Windows since the manufacturer is eager to test there etc etc

Knowing the all important fact that all hardware suck I'd argue that its
not a driver issue. :)

> But it's still an issue so we need to blacklist it. Indeed, the HAL
> has very good infrastructure for blacklisting devices. You can simply
> write an device information file that matches the drives and merges
> the property, say, "storage.no_auto_mount" and hal would respect this
> by not polling (hal polls just like magicdev), g-v-m would respect
> this by not automounting and finally gnome-vfs / Nautilus would always
> show the drive. (it's trivial to add support for this property).

Implementing this should be pretty easy. There is even a is_user_visible
boolean in GnomeVFSDrive. However, won't it look pretty strange if it
only does this for some random subset of drives?

> Device information files are a lot easier to distribute than the
> current way of blacklisting AFAIK. Vendors, communities, OEM's or
> whatever can provide these; perhaps a policy piece in GNOME or at the
> distro level might obtain it on-the-fly from a HTTP server. There are
> plans to add cryptographic signatures to device information files as
> well.
> 
> > * Putting in a CDRW that you want to burn something new on will mount
> > it, and block burning or erasing.
> 
> Well, HAL does examine the disc and exports volume.disc.* properties
> that includes whether the disc is blank, appendable, has audio, has
> data etc. The policy I would suggest (and this is what I have in my
> patch today) is to show the icon for a blank (CD|DVD)-R[W] but not
> mount the disc. When the user clicks he is taken to burn:///. If the
> disc has data and is appendable it is indeed mounted and the user sees
> data.

Yeah, but a non-appendable CDRW disc with actual data can still be
written to, you just have to erase it when writing.

> Notwithstanding all this, this cd burning apps are able to unmount the
> volume themselves (part of the utopia stack updates the fstab entry
> with flags user) and they could acquire an advisory lock on the hal
> device to signal that the device is being used exclusively and no
> other application using hal would touch the device and hal itself
> would stop polling (note, not yet implemented but see discussion on
> xdg-list Sep/Oct 2003). 

Sure, we can work around all sorts of things in all the apps. Its just
an example where things break down.

> > * Putting in a audio CD with a filesystem on will mount the filesystem
> > and might block playing the audio.
> 
> This is a real problem yes; it would require a change to the kernel
> driver. Btw, this works on Mac OS X, it's kind of cool. I suppose that
> applications wanting to play audio CD's would have to unmount the data
> part. Dunno how that will work though. Either way, it's a corner case.

Not doing really bad on the corner cases is important though. Suddenly
refusing to play some audio cd doesn't make the OS feel robust and
stable. And I'm pretty sure the audio cd players won't all get this
right, and anyway is randomly unmounting all mounted cds when you launch
the cd player/ripper/whatever the right thing to do?

> > Maybe in an ideal world. In practice however i think we'll uncover lots
> > of small problems with automounting.
> > 
> 
> But isn't these problems just an effect of broken drivers and not
> broken hardware? (again, I have no real data other than it works on
> other operating systems etc. etc.)

If you ask kernel guys they will tell you all hardware is broken. That
seems to be the norm, especially with cheap pc hardware.

> > The last time this argument was going on I ended up on the pragmatic
> > side, going with devices visible in the UI. I feel that there are good
> > arguments on both sides, however we once made a decision, and its now
> > implemented and even exposed in the APIs. So, I would prefer if we kept
> > the current way instead of changing again. At least thats my current
> > opinion, although I don't violently disagree with your position either.
> 
> Ok, I'll admit my position isn't really pragmatic (I assume that all
> drivers and hardware just work according to spec), and, oh, maybe I do
 
You will learn truth eventually and become old and bitter like the rest
of us.

> feel a bit stronger about this than earlier noted and surely I'm
> ignoring all the corner cases with broken hardware/devices and the
> support issues re: hardware that OS vendors has every day. 
>
> Anyway, would you accept a patch that reads a gconf value whether to
> show/hide drives or not? :-)

Of course not, that would be the absolutely worst "solution". Whenever
things don't work people will turn on showing drives to work around it,
and we'll never get to fix the bugs. Instead there will be two totally
different models of handling volumes out there amongst users and lots of
random ideas when to apply this workaround.

Not to mention, I'll be the one getting all the flames for "nautilus"
breaking whatever broke due to automounting. :)

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a suave shark-wrestling matador with a winning smile and a way with the 
ladies. She's a mentally unstable communist cab driver looking for love in all 
the wrong places. They fight crime!