Re: VFS for legacy apps (was: gvfs status report)

[Alexander Larsson <alexl redhat com>]

On Thu, 2007-02-22 at 14:51 -0600, Hans Petter Jansson wrote:
> On Thu, 2007-02-22 at 14:44 +0100, Alexander Larsson wrote:
> > In fact, its likely they implement this by just stat()ing all the files
> > in the recent list. This is a great example of where automounting would
> > royaly screw things up. Given a traditional unix system there wouldn't
> > be anything bad with a solution like that (in fact, it would be very
> > nice to not show deleted files in the recent menu). However, if any stat
> > can lead to indefinite blocking and displaying of random authentication
> > dialogs you suddenly have to do something much more complicated in order
> > to not suck.
> 
> That's a good point. To make that suck less, you'd probably have to
> 
> - Immediately deny any access to unmounted shares.
> - Pop up a dialog asking the user if it should be mounted (if the mount
> metadata could be converted to a more display-friendly string, such as a
> URI or even a chosen name, that would be great).
> - Optionally mount it.

So, when the app reads the data for recent files and stats it, or does
some other similar operation you'll pop up a dozen dialogs allowing you
to mount things like ftp.gnome.org again. You click "no" several times,
and two seconds later they all pop up again. Believe me, things like
this happen, all the time. I have to be extremely careful in nautilus
for example to never ever access (even get info about) things like
history or bookmarks except when the user explicitly browse into them,
otherwise we pop up dialog to left and right, when the user don't expect
this at all.

I much prefer a system where the app can either just ignore the failed
stat (if it was an "unimportant" operation), or in case an open fails
display an error that the pathname couldn't be opened, with a pathname
that users can understand. Especially when said pathname is also likely
to appear in the user interface (in the file selector).

> The bad part is that the application's "access denied" and the "I think
> you're trying to mount something" dialogs would pop up simultaneously.
> 
> With gnome-keyring integration, this problem would largely go away,
> though. In most cases, gvfs could fetch the auth information
> transparently then go ahead and mount.

Its unfortunate that due to todays stateless gnome-vfs that doesn't ever
reuse server connections between processes we have to use gnome-keyring
as a poor-mans connection-sharing. This is really not a good idea in
general, as it means you tend to store all your passwords (like smb or
sftp passwords that are often the same as your system password!) in
gnome-keyring. Which is *not* recommended as good password hygiene.
(i.e. anyone in front of your unlocked desktop, say when you're on
lunch, can easily extract all your passwords from gnome-keyring. Handing
out passwords is after all what gnome-keyring is designed to do.)

Lets not propagate such use further.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a lounge-singing albino jungle king with a passion for fast cars. She's a 
chain-smoking cigar-chomping doctor who can talk to animals. They fight crime!