GNOME Bugzilla – Bug 148888
ftp method doesn't like ~ as a path name
Last modified: 2004-12-22 21:47:04 UTC
Trying to access the free webspace provided by Demon (uk ISP) it doesn't work specifying ~ in the path. gnomevfs-ls returns "Not a directory" Manually expanding this to the full path, found out via a pwd once logged in from the console ftp, and using that in the uri works just fine. The problem there is that this isn't guarenteed to stay the same, so working with ~ would be preferable.
As far as I can tell (from skimming the RFC) the FTP protocol doesn't support the concept of "home directory." The best we can hope to do here is to respect the default cwd that we are given at login and build paths relative to it in the case of some special character in the path... Personally, a URI like ftp://host.com/~/my/files sort of scares me :)
There's not really a clean way to do this. Having, for example ftp://host/~/file and ftp://host/your/home/dir/file be the same file is a bit ugly. Unfortunately, the URI mechanism isn't good at handling relative path names. This is a WONTFIX.
Created attachment 30480 [details] [review] support ~ in ftp:// uris The attached patch adds support for using ~ in the path. It has one problem in that you can't get file info for /~ or at least with the Demon server you can't due to not having permissions outside of your home directory. Obtaining file info for files / other directories under ~ works fine. I hope the wontfix decision can be reversed as this is something that is very much needed and far more usable. Without going outside of gnome and using another ftp application it is impossible without this patch to use ftp:// unless you know the full path to your files.
I think your patch won't work if the user wants to access to a directory named '~' on the server. Moreover, if we support ~ for ftp, it needs to be implemented for all methods for consistency imo.
That would only refer to files in the root directory though, and is an acceptable trade off IMO. The patch should really check for /~/ rather than /~ as well to allow for /~filename etc. Consistancy is a problem I guess, so it probably should be supported in any method where a home directory can possibly exist. ~ appearing in a URI is not exceptional either, as it is seen in http with ~username being setup to be ${HOME}/public_html for instance.
Having ~ in a URI is an unfortunate hack to get around a problem that should be solved with an improved user interface. If the correct URI for a file is ftp://host.com/home/user/filename then that's the URI that it should be refered to by (always). It seems likely that a future version of nautilus will have a 'connect to login directory' option to make this a lot easier.
an improved user interface? How exactly can an improved user interface provide the location of a resource on a remote machine? You seem to be totally ignoring my point that a user may not even know the correct URI for their files / directories and do not know how to find it out. I presume by nautilus that would be libgnomeui, but does that mean that the ftp module will provide a control method to return the login path? If not it is impossible for any gnome-vfs using application to transfer files / directories to / from that location as they do not know the path.
Here is a part of the IRC conversation related to that: « <alex> ~ expansion should always be done in apps <alex> and in the case of ftp ~ doesn't even always exist <desrt> alex; i think there needs to be some kind of an API to get the "default" folder on a server <desrt> then nautilus could come up with an easy way for the user to navigate to it <desrt> teuf; it was requested as home directory... but ftp doesn't support "home directory"... so, it turned into "default directory" <alex> sure, there could be some such API to help nautilus »
Created attachment 30574 [details] improved connect dialog mockup David: This is what I had in mind in terms of the UI. This, of course, would be supported with new API from gnome-vfs (possibly circa 2.9)