Re: VFS for legacy apps

[nf2 <nf2 scheinwelt at>]

Alexander Larsson wrote:
> 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).
>   
Perhaps application developers could be made aware of this mounting 
issue by providing special functions in the gvfs api (to make 
automouting possible, but in a controlled way).

if (!g_file_is_on_mounted_fs(GFile *f ...))
   g_file_try_async_activate(GFile *f...);    // will pop up the login 
dialog and mount

// ... work with the file ...

Btw, how would you deal with the "operation queued" case, which causes 
similar problems...

I tend to understand now why KIO provides async methods only ... (or a 
pseudo synchronous, which keep the main-loop iterating). This protects 
developers from using the synchronous api and freeze their GUI...

norbert