GNOME Bugzilla – Bug 509620
Implement ftp backend
Last modified: 2008-03-03 21:25:50 UTC
We want an ftp backend.
Yes we want it ! :) Is there any guideline or sample code to write gvfs backends ?
None atm. There are a bunch of other backends though, and we'll gladly answer specific questions.
Alex, I'm marking this as a 2.22 showstopper for now (although we can punt this quite easily) since it's a visible regression for many people. Do you have any idea how hard it is to write one? Is the gnome-vfs module a good starting point?
I wouldn't say its "hard", but its sure a lot of work. Christian Kellner started working on some network APIs that will make this a lot easier, and then I'd propose lifting the ftp listing parser from some other place (curl or wget perhaps?). The gnome-vfs ftp backend is not really that good, so we shouldn't lift to much from it.
so is anybody currently working on this, or plans to work on this until 2.22? otherwise i'd call for help.
Nobody is working on it atm. Christian Kellner may have time to work on it some time in the future.
The plan is to use the socket/network API in development paired with a ftp listing parser from libcurl or wget. I'm making this bug depend on the gio network API bug. Of course, that will probably not land in this release, but we can use that code by cut and paste and statically linking it into gvfs.
I should probably mention here that I am working on this.
Created attachment 106111 [details] [review] code dump 02-27 Here's my current state. It allows downloading files, listing directories and querying (some) attributes. Tested on localhost, ftp.microsoft.com and ftp.blizzard.com and it worked "ok". I'm looking for testers (with different ftp servers), suggestions for the FIXMEs in the code and general code review. Also, if you have fundamental problems with it, please complain now.
I've committed it, because it's easier for people to test that way. I'll close this bug when I think the backend is feature-complete enough.
Benjamin, while the backend works (a quick on my ftp+login provided by ISP), there are some Nautilus weirdness: * suggests the "autorun software" to open the ftp mount * no "folder" icon for folders * "/" as window title for root * UI freezed while loading (no async?) Also I tried to use the Connect to Server dialog and it showed me the message: Failed to execute child process "/opt/gnome2/lib/firefox-2.0/firefox" (No such file or directory) Why in the hell Nautilus tried to run firefox for ftp://?? Oh, and of course there is (yet?) no gnome-keyring support.
(In reply to comment #11) > > Also I tried to use the Connect to Server dialog and it showed me the message: > > Failed to execute child process "/opt/gnome2/lib/firefox-2.0/firefox" (No such > file or directory) > > Why in the hell Nautilus tried to run firefox for ftp://?? > Forgot to mention: the plain "Open Location" dialog, instead, works fine.
I've had a quick look, here are some random comments: There is only one connection used, and even if multiple were allowed there are some servers that only allow one connection. This is a problem when we open a file, as this claims the connection exclusively until the file is closed. This is problematic in the case of multiple open files, as it can lead to deadlocks. The standard example is when copying a file to another location on the same ftp server. Its kinda hard to handle this, but I think at least some ftp servers support cancelling and resuming an upload/download, so it should be possible. I didn't verify this, but I think the error handling on open_for_read/write has to be a lot more detailed, as nautilus relies on quite some specific errors. For read we just have to make sure G_IO_ERROR_NOT_FOUND and G_IO_ERROR_IS_DIRECTORY is correct, and for write also G_IO_ERROR_EXISTS. Also you need to handle G_IO_ERROR_NOT_FOUND in query_info and enumerate and G_IO_ERROR_NOT_DIRECTORY in enumerate. When backup is not supported, error to use is: G_IO_ERROR_CANT_CREATE_BACKUP Display name: This assumes same filename encoding as for local files. This isn't ideal, but i guess its ok until we add per-mount configuration options. However, since the default is not always UTF8 you should call g_vfs_backend_set_prefered_filename_encoding() to set the one that is used. do_query_info: g_file_info_set_name (info, filename); This is wrong, should be the basename. While NLST is easy to parse its kinda limited. Using it means we will never support for instance symlinks or file ownership/permissions details.
Luca: You probably have a /desktop/gnome/url-handlers/ftp/command gconf key set.
(In reply to comment #11) > * suggests the "autorun software" to open the ftp mount > That's a problem with query_info not being able to tell if a file exists or not, I'm working on it. > * no "folder" icon for folders > Fixed in my most recent svn comment. > * "/" as window title for root > I'll have a look. > * UI freezed while loading (no async?) > Directory listings are sloooooow. Lots of people complained about that already.
> > * UI freezed while loading (no async?) > > > Directory listings are sloooooow. Lots of people complained about that already. ... the panel seems freezed too > Luca: You probably have a /desktop/gnome/url-handlers/ftp/command gconf key > set Unset. But now the connect dialog says it can't display the location 'cause the specified location is not mounted ... ??!!??
I'm gonna close this bug now. The ftp backend works good enough to not be in the "unimplemented" state anymore. Please file new bug reports for the huge amount of bugs you will find.