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

On Thu, 2007-02-22 at 14:44 +0100, Alexander Larsson wrote:
> On Thu, 2007-02-22 at 13:49 +0100, Alexander Larsson wrote:
> > On Thu, 2007-02-22 at 10:33 +0100, Alexander Larsson wrote:

> > As a further example of this I tried OSX. It has a system similar to the
> > first proposal. I.E. When you mount smb://server/share in the finder it
> > appears as the unix mount /Volume/server;share, and connecting to
> > gives you a /Volume/ mount.
> > 
> > It handled the recent files case by not showing the recently opened file
> > in the recent files menu when it was on a share that is no longer
> > mounted. However, if I remounted it it appeared again. (Although i did
> > have to restart the app, which is sort of crap.)

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

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.

Sure, it'll block the calling application, but if it's using a blocking
open(), it always blocks to some extent anyway. We could make the
timeout fairly short (say, 10 seconds) when we know we're dealing with a
legacy app.

Hans Petter

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]