GNOME Bugzilla – Bug 326533
opening from a ftp that allow only one connection doesn't work
Last modified: 2009-11-04 19:04:12 UTC
Please describe the problem: The drag and drop from a distant ftp location opened in nautilus to a gedit window does not open the document. The tab is added to the notebook, with a red icon, and then immediatly disappears. This causes an error message to be displayed in the terminal : > (gedit:14341): libgnomevfs-WARNING **: trying to read a non-existing handle Steps to reproduce: 1. Connect to a ftp server (with password) and open it in nautilus 2. Choose a file with a pretty icon 3. Drag it to a gedit window Actual results: A tab is created for the file, and immediatly disappears. The above error message is shown. Expected results: The file should be opened, or an error message should be displayed if it can't be read (as for -r flags of local files) Does this happen every time? yes Other information: - checked that I have the rights to edit the file. - as expected, adding ftp to the “save-enabled” schemes does not change anything.
Update after pbor's patch: The error message is not printed anymore, and the behaviour is slightly different: When I drop the file on the gedit window, an empty tab appears and the keyring ask for access grant. If I hit "allow once", it asks a second time and the file is loaded correctly. If I hit "always allow", the tab disappears (it shows a red warning icon for a second), the file is not loaded and no error message is printed.
Well, the behaviour is in fact way more random than what I thought. Just an idea: given that ftp servers usually only allow a limited amount of connections from a given host, is it possible for the cause to be that that limit would have been reached, because gedit tries to open one more connection ? If this is the case, then the bug comes from gnomevfs, and the only solution would be to share connections accross every gnomevfs-enabled app...
The server where the bug occured only allowed two connections per host. This amount has been bumped to 5 and now it works fine. This is definitely the cause of the bug. The unavailability of the file (cause it can't connect) should be catched and shown as a notification area.
Ubuntu bug about that: https://launchpad.net/products/gedit/+bug/51610 "When I open a file that I have mounted with GNOME (Places... Connect to server), gedit will fail to open this file without any error message at all. I'm running the latest edgy on x86. ... > There is a bug with the same message described upstream: http://bugzilla.gnome.org/show_bug.cgi?id=326533 > which seems to be due to the limitation of the number of connexions to the server. How many connexions are you authorized to open? ... Just one connection. A workaround would be for gedit/nautilus to cp the files to /tmp and then reupload them, when finished: similar to gftp functionality. ..."
<paolo> nud: can we move bug #326533 to gnome-vfs? <bugsbot> paolo: Bug http://bugzilla.gnome.org/show_bug.cgi?id=326533 nor, Normal, ---, gedit-maint@gnome.bugs, NEW, opening from a ftp that allow only one connection doesn't work <nud> dunno <nud> imho we should show an error message <nud> now it fails silently
Forgive me if this has been superceded by another bug but this is the only related one I could find. I'm still having ths problem after the move to gvfs. I am getting an error message in gedit between the toolbar and the box where the file contents should be. It happens when I try to open a file on a server limited to one or two client connections. It seems that for each concurrent file I attempt to open, an additional connection attempt is made to the server. This is verified using Wireshark - the FTP server returns "521 Too many users". I also encounter similar problems when simply browsing a remote server with nautilus. I haven't been able to establish a pattern, but often it seems that more than one connection attempt is made even for listing remote files, or viewing properties of remote files. When this happens Nautilus doesn't display any message but hangs for several seconds. IMHO although I see no problem with this behaviour, I think it should be configurable somewhere as there are many FTP servers out there with such limits - in my case most of them are commercial Windows-based daemons where the number of simultaneous connections is related to the licensing cost of the FTP daemon. I would never consciously choose such closed-minded software for my own servers but unfortunately I don't have a choice when dealing with customers' servers. If this is not specific to, or indeed the responsibility of gedit, should the bug be assigned to the correct application?
I've got the same problem (webserver hosting my webpage allows only two connections per user). Does somebody know a work-around .. ?
Is this still relevant now that we use Gio/gvfs?
It doesn't seem to be a problem any more with Ubuntu 9.04 (all updates). I haven't had a crash during the last few minutes of testing a mounted ftp server. Drag'n drop (as described by Steve Frécinaux) worked without any problem, and i didn't get any error saying "Too many users" any more (that's the problem Tom Bamford posted).
Sorry for the delay in replying to the recent comments. Unfortunately the latest Gnome version I can try is 2.24.1 on an updated Ubuntu 8.10; I can't afford the bandwidth for the 9.04 ISO yet. I also don't have access to the same FTP servers, but I installed vsftpd and limited concurrent connections to 1 to try and repeat the bug, and the problem still exists to a degree on my version. Previously I couldn't get more than one directory listing, nor upload, download or attempt to edit any file directly in a Gnome app such as text editor. Now, I can browse (get listings), and download one file at a time. The daemon cuts the connection straight after a single download but it does download. I still can't edit files 'directly' using gedit, eg. double clicking on a remote text file. I get this error msg: Could not open the file ftp://tom@localhost/home/tom/Documents/mac-oui-list.txt. Unexpected error: Host closed connection I'll attach an excerpt from the ftp daemon log which shows the daemon disconnecting the client due to too many concurrent connection attempts. I don't know what the best practise would be in a situation where a remote server allows a single connection per user, or per host. Using >1 connection is desirable if the server allows it; if there is some way to gracefully degrade to using one connection if that's all the server permits that would be great - but it doesn't look that simple. The proprietary daemon I was forced to use when I made my earlier comment returned an error code of 521, but vsftpd seems to be using 421 for the same condition. From my reading there doesn't seem to be a proper code for saying 'too many connection attempts' or 'too many sessions', if this is so then it's going to be left up to the error text which is going to be different for every implementation. The more I look into this the less I think there is anything you guys can do about it. FTP really sucks...
Created attachment 135402 [details] vsftpd error log
I don't know why I thought I was fully updated, having just checked there are a number of Gnome updates I have outstanding, including gedit. I just can't afford the 300MB to get them (on GPRS in South Africa). Guess I can't confirm whether or not this issue has been overcome, sorry :(
I think this bug should be fixed by the recent switch to GIO. If not, feel free to reopen.