Re: SMB status

[Alexander Larsson <alexl redhat com>]

On Fri, 2008-09-19 at 20:08 +0200, Tomas Bzatek wrote:

> Since gvfsd-smb-browse is automounted, we're still facing the blocking
> issues across whole Gnome desktop - several applications use blocking
> query_info() calls in hope the stat will be fast. Well, it actually
> isn't that fast and such usage should be handled asynchronously. For
> example gnome-panel still has 6 sync query_info() calls in utility
> functions, which are used everywhere. What we can do here is to optimize
> gvfs not calling full stat if user application requests just
> standard::display_name or so (this is on my todo list...). From what I
> heard there's a similar blocking issue in gvfsd-http.

If we make the smb-browse backend authenticate, then we just have to
disable auto-mounting of it. This means the apps doing sync i/o on it
will get a (fast) ENOTMOUNTED error instead of freezing.

> 
> What has been fixed:
> - I decided to encode username and domain (if set) to the URI string
> just like for other backends. This will fix several issues where freshly
> mounted share couldn't be found (actually it led Nautilus to mount the
> share for the second time). I tried to find out the purpose of not
> including username in URI but couldn't find any -- Alex, please confirm.

Yes. This is right. It boils down to this:

The uris foo://user host/ and foo://host/ maps to two different mounts,
even if "user" happens to be the default username. URI mapping between
these two needs to be one-to-one, but if you set the username on the
mountspec for the second uri then mapping back to uri will add the user,
and if you re-map the same uri you just mounted you won't get to the
right mountspec.

This is done both for implementation simplicity/efficiency reasons, but
also to ensure a nice default behaviour. In the default case where you
enter a name+password you don't want to hardcode the username that the
user specified in the password dialog in all resulting uris from this
session (that get stored in various persistant places). The username was
not specified in the URI, so why should it be specified in resultant
URIs? Its both redundant and potentially problematic if you later e.g.
re-login to get better access permissions.