GNOME Bugzilla – Bug 322394
SFTP URLs do not follow specification
Last modified: 2018-08-17 13:49:21 UTC
Please describe the problem: SFTP URLs are not interpreted according to the published specification. Steps to reproduce: 1. run "gnomevfs-ls sftp://remotehost/" Actual results: A directory listing is given for the root directory on remotehost Expected results: A directory listing is given for the user's home directory on remotehost Does this happen every time? yes Other information: The specification for sftp:// URIs is here: http://www.ietf.org/internet-drafts/draft-ietf-secsh-scp-sftp-ssh-uri-03.txt It says that "sftp://remotehost/" would be interpreted as the directory "" relative to the user's home directory, while "sftp://remotehost/%2F" is the root directory on remotehost.
+1 It's a shame we can't address bug 148888 with something similar :/
ftp has the same problem (according to the ftp uri rfc). However, i'm not at all sure that this will work for gnome-vfs. Apps really expect gnome-vfs uris to work in a specific way, and this will break that.
It seems that the main issue is listing the contents of the top level path in the URI (which is the home dir plus top level dirs with a slash prepended). I can think of two ways to handle this: * give a directory listing of the sftp path "" (the home dir) followed by a listing of "/", with the slash prepended to the results. * give a listing of "", plus an extra "/" entry, and then let people list sftp://hostname/%2F to get the toplevel directories. Is there any other issues?
> Is there any other issues? The issue is that people who don't know the spec have no clue that they have to enter ftp://%2ffoo/bar if they don't want their default home dir.
Christian: either of the two solutions I listed previously would allow navigation to top level directories.
Created attachment 70775 [details] [review] Proposed first shot Newer drafts of the URI spec [1] suggest to use a tilde, i.e. to expand sftp://host/~/ to an URI referring to the home directory. The attached patch implements this. Unfortunately, Nautilus can't deal with these very well because it resolves URIs using string manipulation and supposes / is the parent of /~/. I suggest its algorithms should check for a segment being "~" and returning the info for "some_path/~/..", or maybe this should be done at the GnomeVFS level? [1] http://tools.ietf.org/wg/secsh/draft-ietf-secsh-scp-sftp-ssh-uri/draft-ietf-secsh-scp-sftp-ssh-uri-04.txt
Updating version, assigning to myself.
This is something that's bothered me for a long time. My old ISP provided shell access to some of their servers but the path to your home directory was long and complicated (they have thousands of customers) and if you didn't know it already there was no way to get to it using gnome-vfs. I don't think I agree with the RFC in either it's older or new versions, though there are advantages to either. If sftp://host//path/file meant an absolute path (%2F is /) and sftp://host/path/file meant a home-relative path that would probably be an ideal solution. It's unfortunate that this would break some applications, or at least some assumptions. A good temporary solution to my own problem (not being able to find $HOME) would be to have gnome-vfs redirect from sftp://host to sftp://host/path/to/home like KDE's kio-stuff does. Does gnome-vfs support redirects? I have only skimmed the RFC but I don't see anything to suggest that such behavior would violate the specification.
Finished reading the RFC. We can interpret paths however we want but it's recommended that the path be considered absolute and we may interpret /~ to refer to the home directory. In this case I think it would still be of value to redirect from an empty path to /~. It seems that this would not actually break anything since old applications would always use absolute paths and only new applications would take advantage of the /~ shortcut.
gnome-vfs got deprecated in 2008. gnome-vfs is not under active development anymore and had its last code changes in 2011. Its codebase has been archived: https://gitlab.gnome.org/Archive/gnome-vfs/commits/master gio (in glib) and gvfs are its successors. See https://developer.gnome.org/gio/stable/ch33.html and https://people.gnome.org/~gicmo/gio-migration-guide/ for porting info. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Feel free to open a task in GNOME Gitlab if the issue described in this task still applies to a recent + supported version of glib/gio/gvfs. Thanks!