I'd think this would work:

  GFile *ret;
  file = g_file_new_for_uri (uri);
  mount = g_file_find_enclosing_mount (file, cancellable, error);
  if (mount == NULL)
    goto out;
  ret = g_mount_get_default_location (mount);
  g_object_unref (mount)
 out:
  return ret;

Sure, but that's not what the bug is about :)

The issue is how you support relative urls or load a new mount in the default (aka home) location rather than "/".

We have two widely used ways of accessing remote shares.

1. Browsing using network://
2. Typing in a URI for the share (from the location bar or the connect to server dialog)

In each case the share is just a uri. In case 1 the network:// location just provides a proxy for the actual target uri that is something like "sftp://192.168.1.100:22"

So when I click on the item in network or just type the equivalent I get an authentication prompt, login, gvfs determines my default/home location and then just plops me into "/" instead of the default location.

One reason for this is that we have no way of knowing when the user wants the default location and when they actually do want "/".

Yes, I just tried it (on F17): Nautilus drops me at / when I type in sftp://1.2.3.4 ... but if I click the corresponding icon in the sidebar, it drops me at /home/davidz. It seems weird that this is different.

So isn't this just a Nautilus bug, e.g. shouldn't Nautilus use the code from comment 1 (same as in the sidebar I guess) when I type in sftp://1.2.3.4 ? (If I wanted /, I'd navigate there myself, I guess).

(In reply to comment #3)
> Yes, I just tried it (on F17): Nautilus drops me at / when I type in
> sftp://1.2.3.4 ... but if I click the corresponding icon in the sidebar, it
> drops me at /home/davidz. It seems weird that this is different.
> 
> So isn't this just a Nautilus bug, e.g. shouldn't Nautilus use the code from
> comment 1 (same as in the sidebar I guess) when I type in sftp://1.2.3.4 ? (If
> I wanted /, I'd navigate there myself, I guess).

Also, for browsing via network://, I'd expect the network:// GVfs backend to also use g_mount_get_default_location() and append those to the target URIs.

(In reply to comment #4)
> (In reply to comment #3)
> > Yes, I just tried it (on F17): Nautilus drops me at / when I type in
> > sftp://1.2.3.4 ... but if I click the corresponding icon in the sidebar, it
> > drops me at /home/davidz. It seems weird that this is different.
> > 
> > So isn't this just a Nautilus bug, e.g. shouldn't Nautilus use the code from
> > comment 1 (same as in the sidebar I guess) when I type in sftp://1.2.3.4 ? (If
> > I wanted /, I'd navigate there myself, I guess).
> 
> Also, for browsing via network://, I'd expect the network:// GVfs backend to
> also use g_mount_get_default_location() and append those to the target URIs.

Pretty sure that isn't possible until after the mount is attempted.

(In reply to comment #3)
> Yes, I just tried it (on F17): Nautilus drops me at / when I type in
> sftp://1.2.3.4 ... but if I click the corresponding icon in the sidebar, it
> drops me at /home/davidz. It seems weird that this is different.
> 
> So isn't this just a Nautilus bug, e.g. shouldn't Nautilus use the code from
> comment 1 (same as in the sidebar I guess) when I type in sftp://1.2.3.4 ? (If
> I wanted /, I'd navigate there myself, I guess).

That would leave no possible way to navigate to "/" using a URI because we don't differentiate "sftp://1.2.3.4" and "sftp://1.2.3.4/"

The core problem with things like "default location" is that actually finding out the value is an I/O operation, and the "semantics" of uris is that traversing them is I/O-less, analogous to the string operations you do when manipulating path strings. And, going up from e.g. ~/ is not possible (and additionally aliasing files like this is problematic).

It works in the unix shell because ~ is expanded by the shell, so things like basename and dirname get the correct result, but there is no such expansion by default when you create a uri (GFile).

However, it might be possible to create a special file on the gvfs backends that work as a shortcut (for instance "sftp://host/~"). That means e.g. nautilus will automatically follow (i.e. expand) the file when opened. Then the network uris could be changed to point to these.

(In reply to comment #5)
> > Also, for browsing via network://, I'd expect the network:// GVfs backend to
> > also use g_mount_get_default_location() and append those to the target URIs.
> 
> Pretty sure that isn't possible until after the mount is attempted.

Yeah, OK, that's a good point. Instead, if the URI "/~" for a mount M meant "expand to default location of M if available, otherwise expand /", everything would be fine, right?

(In reply to comment #7)
> The core problem with things like "default location" is that actually finding
> out the value is an I/O operation, and the "semantics" of uris is that
> traversing them is I/O-less, analogous to the string operations you do when
> manipulating path strings. And, going up from e.g. ~/ is not possible (and
> additionally aliasing files like this is problematic).
> 
> It works in the unix shell because ~ is expanded by the shell, so things like
> basename and dirname get the correct result, but there is no such expansion by
> default when you create a uri (GFile).
> 
> However, it might be possible to create a special file on the gvfs backends
> that work as a shortcut (for instance "sftp://host/~"). That means e.g.
> nautilus will automatically follow (i.e. expand) the file when opened. Then the
> network uris could be changed to point to these.

Is aliasing a problem? I mean, I don't think it's a problem that the two URIs sftp://1.2.3.4/~/foo.txt and sftp://1.2.3.4/home/davidz/foo.txt are different but refer to the same file. Consider for example sftp://1.2.3.4/foo/file.txt sftp://1.2.3.4/bar/file.txt where /foo/file.txt and /bar/file.txt on the target machine are hardlinks or symlinks... I mean, we don't make a lot of guarantees about URIs and what they in general refer to.

(In reply to comment #7)

So there seem to be two cases.

1. the location isn't mounted.
2. the location is already mounted (maybe)

Case 2 is really tricky because there is a bunch of hidden state that is needed to map from the mountable uri to the mount point. Things like username and possibly share name. This is already a pretty nasty problem. So, I think we probably need some kind of uri redirection/rewriting in some cases.

For case 1 I think there could be at a few options.

a) treat the default location as the "share" and consider it the root anyway.

 - disadvantage of making the "/" inaccessible from that mount. Even worse by the fact that we can't do multiple mounts to the same location very well.

b) just alias the ~ internally to the default location.

 - as you mentioned above some things may think it is the root but really is this a problem?

c) rewrite / redirect clients to the new location.

 - yet another bounce - not sure if it will confuse mounting operations since we only know the actual target uri after the mount operation succeeds (or during it).

Aliasing is definately a problem. It means things like recent files, bookmarks, etc will get duplicate version of the same file, just based on how you reached the file. It also means all uri-based comparison breaks, so e.g. the gvfs metadata for the two uris would return different values. 

Its not the end of the world if this happens in some uncommon situtation (like unix symlinks) but we should avoid them as much as possible.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/193.