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

[David Zeuthen <david fubar dk>]

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 :-)

On Tue, May 18, 2004 at 10:26:27AM +0200, Alexander Larsson wrote:
> On Mon, 2004-05-17 at 23:45, David Zeuthen wrote:
> > On Mon, 2004-05-17 at 11:36 +0200, Alexander Larsson wrote:
> > > On Fri, 2004-05-14 at 17:09, David Zeuthen wrote:
> > > > It would be a change, yes. I'm happy to change it though, but I'm not
> > > > sure how to do it in a good way.
> > > 
> > > I'd like that. There are a couple of reasons I like about having icons
> > > for devices for removable media:
> > > * We need it for some types of media. The trivial and most common
> > > example is the floppy, but there is probably more. If we do it for
> > > floppys its nice if we do the same for e.g. cdroms.
> > 
> > Floppies indeed seem to be the only problem if you look at how e.g. Mac
> > OS X handles removable media (not showing drives). Mac OS X has the same
> > hard semantics on mounting removable media like other UNIX-like systems
> > so GNOME should be able to treat media the same way.
> 
> 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.

> 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

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

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.

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

Yeah, this would require all running applications touching hardware to
use hal, but due to the hard mounts that UNIX-like systems use this is
quite neccessary cf. the 'fs is busy while unmounting' problem, yes?

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

> * I bet other random hardware will have similar issues to floppies
> (because that sort of hardware will still work in windows). Things like
> jaz/zip drives and similar. Apple control all their hardware, so they
> can avoid this, but we do not. 

A lot of the hardware that people attach to Apple computers are in
fact 3rd party USB or Firewire stuff and it works just fine.

> For instance, do usb flash card readers
> give a signal when you plug a flash card in them?
> 

The kernel wont tell because of broken drives (see discussion on
linux-hotplug Jan/Feb this year), but HAL polls so yes it works. At
least my devices (and others I've heard).

In general, I'd argue that pollling works and will work on storage
devices using the SCSI protocol such as USB or Firewire otherwise it's
a driver bug. I strongly suspect Mac OS X does polling as well (but
probably on the kernel level) since a lot of 3rd party USB and
Firewire devices works on Mac OS X. And yes, they probably have lots
of work arounds in their USB or Firewire class driver implementation.

Either way, we can easily blacklist this as well.

> > Now suppose floppies is really the only problem and there existed a
> > gnome-vfs module using mtools, would you consider including that module
> > in gnome-vfs. Would OS vendors ship it? 
> > 
> > (disclaimer: I'm not sure how that would work, so please advise if it's
> > been tried before etc. etc.).
> 
> KDE uses something like this, so I think it could work. We could ask
> them if they've had any issues with it. It needs some integration in
> gnome-vfs so that the floppy uris automatically ends up as volumes, but
> that should be possible (and that sort of thing was planned anyway).
> 
> How would it look though? A constantly availible floppy icon per floppy
> drive?
> 

That would be my bet, yes. And also for devices that doesn't support
automounting we would need to display the icon all the time. This
would include blacklisted devices, yes. I'd also use icons that
represents the media of the drive instead of the drive itself. The
worst case we put up a dialog saying there is no media and ask the
user to insert media.

> > > * It gives a location in the user interface where you can discover the
> > > media-related hardware. And its stable, so when you mount it the volume
> > > icon is in the same place as the cdrom was.
> > > * We are exposing "unmount" to users, since they have to remember to
> > > unmount e.g. a usb media before yanking it. This automatically gives you
> > > the state "media in device, but not mounted", which makes it sensible to
> > > expose the dual operation (mount) to be "complete". And mount requires a
> > > device representation before the volume is mounted.
> > > 
> > 
> > First of all I think it would be visual clutter to expose drives without
> > media in the user interface. After all the user does know what drives
> > are available since he is sitting right there in front of his computer
> > or printer or where ever the drives are physically placed. 
> 
> Not horribly so. Its only in computer, which you look at exactly when
> you want to interact with drives/volumes. Only mounted volumes show up
> on the desktop.
> 

I'd still argue it's a weird mixture of two quite different concepts
namely drives and media.

> > Further, for discovering devices handling removable storage I think
> > something like hal-device-manager [1] (but written properly etc.) would
> > suffice. In fact, I've seen many users on Windows get scared of all the
> > grey icons with very odd letters like C:, D: etc. Especially Windows
> > screw you here with multi-card readers; the user has to manually try
> > four drive letters to find his media. In GNOME, it's not unlikely that
> > the name of icons for the drives in computer:// would be plain odd like
> > 6in1-MMC/SD.
> > 
> > Second, if you assume the floppy issue is solved, I simply see no need
> > for not automounting volumes. Going to the extreme I submit it's a bug
> > in gnome-volume-manager that the user can turn off automounting.
> 
> 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.)

Would you rather have these problems not be reported? Anyway, I've
described a way of easily blacklisting problematic devices so it would
be very easy to at least fix it temporarily by providing a device
information file until someone fixes the driver. This could even be
set from some hal-device-manager-like application. Probably still a
huge headache for OS vendors; I dunno..

> > Third, I think I would find it rather confusing that an icon changes
> > from a drive icon to e.g. a compact flash icon and back. Icons in
> > computer:// should really try to represent spatial stuff users relate to
> > like a piece of compact flash media, an icon of a camera, a music
> > player, a DVD disc and maybe even a file server. Users don't relate as
> > strongly to the drive, that's just boring necessary glue that enables
> > them to use their media.
> 
> I strongly interact with my usb flash card reader, although perhaps not
> as much with the built-in media readers in the computer.
> 

You should really interact with the media instead, that's probably a
lot more interesting than a piece of 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
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? :-)

Cheers,
David