Re: [PATCH] computer:/// should display all drives, not only user-visible ones

[Alexander Larsson <alexl redhat com>]

On Wed, 2006-05-31 at 18:36 -0400, David Zeuthen wrote:
> Hi,
> 
> Any reason this is not on the list? Also, please use my david fubar dk
> email address since that's what I'm using for GNOME stuff.

I dunno, it got removed at some point. I'm adding it back.

> On Mon, 2006-05-29 at 14:04 +0200, Alexander Larsson wrote:
> > On Wed, 2006-05-24 at 21:38 +0200, Xavier Claessens wrote:
> > > Le mercredi 24 mai 2006 à 17:59 +0200, Alexander Larsson a écrit :
> > > > Here is the thing. I don't expect there to be a GnomeVFSDrive for
> > > > the /home volume (which i assume is a normal mountpoint on another
> > > > partition). We should only have drive objects for real removable media
> > > > mountpoints.
> > > 
> > > I join a simple program I made which lists all your drives and volumes
> > > and says if they are user visible. It's what helped me understand how
> > > GnomeVFS works :-)
> > 
> > This seems to be a bug in the hal version of the monitoring. We're not
> > supposed to be creating drive objects for all harddrives in the system.
> > A Drive is supposed to be something you can insert a removable volume
> > in, like a cdrom reader, a floppy reader, or a usb card reader. On my
> > system hal creates a drive for e.g. /mnt/hdb1 which is a normal ext3
> > filesystem mounted at roottime and not user-mountable. This shouldn't
> > only exist in the volume monitor as a non-user_visible volume, not as a
> > drive. This used to be papered over in computer:// since the volumes for
> > the drives were always mounted and not user-visible, so they got
> > hidden. 
> > 
> > David, I don't really know the hal stuff. Could you look into this?
> 
> So I'm not really sure why we want this difference you are describing.
> In fact I'd argue that we indeed want to show volumes from e.g. the
> internal hard disk for e.g. your Windows and OS X partitions. 
> 
> And this indeed requires a GnomeVFSDrive because the partition may not
> be mounted and we only have a GnomeVFSVolume for a GnomeVFSDrive when
> the partition the GnomeVFSDrive represents is actually mounted (that's
> my understanding of the how Gnome VFS works).

The initial design for drives was to represent devices that use
removable media (such as cdrom drives, floppy drives, usb card readers,
etc). For these devices the operations on the device are "natural" to
the user. Its true that one can also view them as just "possible
mountpoints for volumes", which means you could have a drive for your
OSX or windows partition. However, when you expose this in the UI you
suddenly turn a very explicit obvious hardware mapping into a way to
expose the much more vague and complicated unix operation of "mounting a
filesystem". I.E. you remove the mapping from icons in the UI to
hardware units you can put stuff into.

If you take the view of a non-unix person (i.e. one unaware of the
details of mountpoints etc) using a Gnome desktop with a separate HD
you have basically three cases. Either the partition is mounted, the
user is allowed to mount the partition, or the user isn't allowed to
mount the partition. In the first case we clearly should show a volume
icon, and in the last case i argue that we should never show a drive
icon (it would do nothing but confuse people). 

The question is what to in the second case. In an ideal desktop system I
don't think that state really is very useful. What non-sysadmin-related
use would you have for not mounting that volume if you are allowed to
mount it anyway? In the case on a non-ideal unix system the question
gets complicated and turns into a question about whether the mountpoint
is an "internal implementation detail" of the filesystem mount tree or
not, and this becomes very similar to the question whether to expand
symlinks or not (don't expand /home to /mnt/hdb/home, but expand
~/Desktop/music to ~/Documents/MyMusic). Some cases are simple, you
never want to display /, /proc, /sys, /dev/pts, /boot, etc. However, for
others things are not so easy. I have for instance /mnt/hdb1 on my
system where i have symlinks like /opt -> /mnt/hdb1/opt. I wouldn't want
to display this.

Whether to show such drives or not is clearly a complicated,
system-dependent issue and should be solved in the lower layers, and not
solved in each app using gnome-vfs.

The change that resulted in this being an acute problem was that we
decided to hide drives that support auto-mount in all places but
computer:// by using the is_user_visible flag of the drive. Doing this
means that flag is used for that and can't also be used to flag whether
a drive is "internal" or not. I think just not having drive objects for
internal mountpoints is the easiest solution to this.

> So I think what you want is to hide is exactly volumes that are mounted
> on traditional FHS mount points, e.g. /, /usr. I can't see why we should
> enforce this policy in Gnome VFS when the bits above (e.g. Nautilus,
> Filechooser) can handle this much better?

I don't understand how you think nautilus can handle this better? 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a gun-slinging voodoo master criminal whom everyone believes is mad. 
She's a strong-willed impetuous detective descended from a line of powerful 
witches. They fight crime!