GNOME Bugzilla – Bug 561998
Have specific entry points (paths) for mounts (e.g. home dir on [s]ftp)
Last modified: 2010-02-16 12:02:01 UTC
Please describe the problem: Hello. When you type sftp://myuser@192.168.0.10 in the address bar, nautilus shows you by default "/" and it should move to "/home/myuser" as ssh does by default. Steps to reproduce: 1. Get a ssh shell 2. Open nautilus 3. type sftp://youruser@ip Actual results: / Expected results: ~ Does this happen every time? Yes Other information:
we have a similar bug here: https://bugs.edge.launchpad.net/ubuntu/+source/nautilus/+bug/290703 ; is this actually a nautilus bug or more like a gvfs issue?
This is definitely a GVFS bug (not only for SFTP but also regular FTP and probably other protocols as well).
If you have no rights to access the root folder, you get an ugly error consider: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/312722
This looks like duplicate of bug 144006. According to bug 144006 comment #7, address bar should be interpreted as URI (by gvfs). I first thought that sftp://myuser@192.168.0.10 sftp://myuser@192.168.0.10/ should be treated differently, but unfortunately the spec (rfc3986#section-3.3) disagrees :/ They're both the same, and relative paths cannot be specified if authority (myuser@192.168.0.10) is included. I still wonder however if Nautilus could handle this as a special case and interpred absolutely empty path component as request to go home dir and change URI in address bar to sftp://myuser@192.168.0.10/$HOME? Requesting '/' as path can still go to root. URI spec wouldn't be broken in gvfs and no functionality would be lost. Command line scp handles this differently, and doesn't seem to even pretend to use location specified as URI. Path component is separated with colon, and relative paths are such accepted. URI spec says that colon is followed by port number, and gfs/nautilus seem to work that way, as expected. For Nautilus, current behaviour is counter-intuitive for both people used to scp, and new people who don't know this technical background. Also, on real multiuser system where there can be more than 10000 users, user home definitely ain't just /home/user, but something more complex, it cannot be resolved easily without some experince with command line (and ssh access). In such cases it's quite vital from user POV that sftp://myuser@192.168.0.10 goes to user home dir. Maybe product should be changed to Nautilus for this bug?
This is also being discussed Ubuntu downstream: https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/290703 Is it possible to GVFS level redirects in nautilus? SFTP layer would return "redirect response" for sftp://myuser@192.168.0.10 and it would go to sftp://myuser@192.168.0.10/home/whatever, the actual location given by SFTP protocol. In HTTP redirects for URLs not ending to / common so at least web browsers respect this kind of behavior is respected even though it violates the spec. (For slash redirect example, see form handling and Django).
Related SFTP spec: http://tools.ietf.org/id/draft-ietf-secsh-filexfer-13.txt File names starting with a slash are "absolute", and are relative to the root of the file system. Names starting with any other character are relative to the user's default directory (home directory). Note that identifying the user is assumed to take place outside of this protocol. Servers SHOULD interpret a path name component ".." (Section 13) as referring to the parent directory, and "." as referring to the current directory. An empty path name is valid, and it refers to the user's default directory (usually the user's home directory) The SSH_FXP_REALPATH request can be used to have the server canonicalize any given path name to an absolute path. This is useful for converting path names containing ".." components or relative pathnames without a leading slash into absolute paths. The format of the request is as follows: byte SSH_FXP_REALPATH uint32 request-id string original-path [UTF-8] byte control-byte [optional] string compose-path[0..n] [optional] So when the connection is opened, GVFS should do SSH_FXP_REALPATH request to the server and return return redirected URI for the user home folder.
I think the place which needs to be fixed is do_mount() in http://git.gnome.org/cgit/gvfs/tree/daemon/gvfsbackendsftp.c However, I'd like to get opinion of someone who manages GVFS first. And get this bug confirmed.
Created attachment 145067 [details] [review] Manny's patch (gio part) Manny wrote a patch for that feature a long, long time ago.
Created attachment 145069 [details] [review] Manny's patch II (gvfs part)
Created attachment 145127 [details] [review] Add "default location" support to GMount * Rename "home" to "default location". * Bit better docs. * Fallback to get_root ()
Created attachment 145136 [details] [review] Add "default location" support for GVfs Backends can use g_vfs_backend_set_default_location () to set the default location (before registering the mount). Example: gicmo@ubudev ~ % gvfs-mount -li Mount(0): sftp on photon.xatom.net -> sftp://photon.xatom.net/ Type: GDaemonMount default_location=sftp://photon.xatom.net/Users/gicmo themed icons: [folder-remote] [folder] can_unmount=1 can_eject=0 is_shadowed=0
Created attachment 145137 [details] [review] sftp backend patch
Created attachment 145283 [details] [review] Add "default location" support for mounts Version two of the patch. This version is dbus backward compatible. I have tested it locally. The g_vfs_backend_se_default_location still doesn't add the mount_prefix since I still think it is not necessary.
Comment on attachment 145127 [details] [review] Add "default location" support to GMount Attachment 145127 [details] pushed as 09b1b64 - Add "default location" support to GMount
Review of attachment 145283 [details] [review]: Looks good in general ::: common/gmounttracker.c @@ +198,3 @@ + if (!_g_dbus_message_iter_get_args (&struct_iter, NULL, + DBUS_TYPE_STRING, &default_location, This should use G_DBUS_TYPE_CSTRING, as this is not guaranteed to be a UTF8 string. ::: daemon/gvfsbackend.c @@ +696,3 @@ + if (!dbus_message_append_args (message, + DBUS_TYPE_STRING, &backend->priv->default_location, CSTRING here too ::: daemon/mount.c @@ +263,3 @@ + if (!dbus_message_iter_append_basic (&struct_iter, + DBUS_TYPE_STRING, + &mount->default_location)) CSTRING @@ +726,3 @@ + if (_g_dbus_message_iter_get_args (&iter, NULL, + DBUS_TYPE_STRING, &default_location, CSTRING @@ +947,3 @@ DBUS_TYPE_ARRAY_AS_STRING DBUS_TYPE_BYTE_AS_STRING G_MOUNT_SPEC_TYPE_AS_STRING + DBUS_TYPE_STRING_AS_STRING CSTRING
Comment on attachment 145283 [details] [review] Add "default location" support for mounts commited with fixes
all right, now we just need nautilus to respect this.
*** Bug 532968 has been marked as a duplicate of this bug. ***