GNOME Bugzilla – Bug 311708
Hang on connection to FTP, with cancel
Last modified: 2008-03-21 18:40:24 UTC
Distribution/Version: Ubuntu Breezy 1. Create a connection to a password protected ftp 2. Double click and open the connection dialog 3. click on cancel 4. When the dialog comes back up, click on cancel a few more times (usually 2 or 3) 5. Observe the can't display connection dialog 6. The OK button cannot be click and the X in the corner activates on click but does nothing reported from here: https://bugzilla.ubuntu.com/show_bug.cgi?id=12995
how do you know what version of nautilus the user is using? do you get the issue too?
Yes, I get the issue, with 2.11.90
Comment on the distribution bug: " I have seen this problem, this evening. I don't have the backtrace anymore (scrolled out of the terminal buffer), but there was a thread specially handling the connection. The thread was hanging in gnome-vfs-inet-connection.c (in gnome-vfs2), line 355. read_val = select (max_fd + 1, &read_fds, NULL, NULL, connection->timeout ? &timeout : NULL); connection->timeout was NULL, so this select was waiting forever (a day anyway) for more data. I'm not sure what state the connection was in, I'll add more data if I see the problem again. It was when attempting to copy a number of files (around 200Mb in size) from the remote FTP server to my desktop. Checking the remote server, I don't see a corresponding entry from netstat, so the NAT gateway may have dropped the entry from its routing table (just a guess). I don't think that having no timeout is good practice anyway if that cancel button is going to work..."
From the Ubuntu bug: "It was Ubuntu Dapper (current packages as of about a week ago). I didn't do anything particularly special to get the hang - I have an FTP icon on my desktop (username set, but no password, so I need to type my password every time I double-click on it). In this particular case, I browsed into a sub-folder, and dragged a folder from there onto my desktop. The folder consisted of the following disk structure: $ ls -ltR .: total 68 drwxrwxr-x 2 gary gary 4096 Apr 7 20:22 stuff drwxrwxr-x 2 gary gary 4096 Apr 7 20:18 translations -rw-rw-r-- 1 gary gary 53688 Feb 20 02:47 stuff.torrent ./stuff: total 5382700 -rw-rw-r-- 1 gary gary 30368 Apr 9 16:12 stuff 06.sub -rw-rw-r-- 1 gary gary 713535492 Apr 9 16:12 stuff 07.mpg -rw-rw-r-- 1 gary gary 31841 Apr 9 16:12 stuff 07.sub -rw-rw-r-- 1 gary gary 26690 Apr 9 16:12 stuff 08.sub -rw-rw-r-- 1 gary gary 711315460 Apr 9 16:12 stuff 03.mpg -rw-rw-r-- 1 gary gary 659871748 Apr 9 16:12 stuff 04.mpg -rw-rw-r-- 1 gary gary 660840452 Apr 9 16:11 stuff 02.mpg -rw-rw-r-- 1 gary gary 676624388 Apr 9 16:11 stuff 08.mpg -rw-rw-r-- 1 gary gary 656570372 Apr 9 16:08 stuff 06.mpg -rw-rw-r-- 1 gary gary 712638468 Apr 9 16:07 stuff 01.mpg -rw-rw-r-- 1 gary gary 714776580 Apr 9 15:55 stuff 05.mpg -rw-rw-r-- 1 gary gary 31781 Apr 9 15:09 stuff 05.sub -rw-rw-r-- 1 gary gary 25928 Apr 9 12:15 stuff 02.sub -rw-rw-r-- 1 gary gary 28091 Apr 9 08:38 stuff 04.sub -rw-rw-r-- 1 gary gary 33666 Apr 9 01:21 stuff 03.sub -rw-rw-r-- 1 gary gary 31408 Apr 8 18:17 stuff 01.sub -rw-rw-r-- 1 gary gary 1362 Apr 7 20:56 translation notes.txt ./translations: total 360 -rw-rw-r-- 1 gary gary 102819 Apr 7 20:18 download.zip -rw-rw-r-- 1 gary gary 1362 Jan 20 04:47 translation notes.txt -rw-rw-r-- 1 gary gary 26690 Jan 20 04:43 stuff 08.sub -rw-rw-r-- 1 gary gary 31841 Jan 18 03:20 stuff 07.sub -rw-rw-r-- 1 gary gary 30368 Nov 7 16:34 stuff 06.sub -rw-rw-r-- 1 gary gary 28091 Nov 7 16:33 stuff 04.sub -rw-rw-r-- 1 gary gary 31781 Nov 7 16:32 stuff 05.sub -rw-rw-r-- 1 gary gary 25928 Nov 7 16:27 stuff 02.sub -rw-rw-r-- 1 gary gary 31408 Nov 7 16:26 stuff 01.sub -rw-rw-r-- 1 gary gary 33666 Jun 7 2005 stuff 03.sub The first few files were transferred almost immediately, and the connection hang when transferring the first large file. A large portion of the file had transferred (certainly over 600Mb), but I can't say for sure if it had finished that particular transfer. When I arrived home after a day away, nothing was being transferred, and the cancel button wouldn't work. ... Since this is 100% reproducible for me, I did a network trace of the whole operation; the result showing that the FTP server (vsftpd 2.0.3) never replied with a 226 on the control channel. The full 712638468 bytes were transferred, followed by a FIN/ACK data channel connection closure initiated by the FTP server. I'll try and pinpoint the vsftpd problem, and possibly file a bug report if it's still in 2.0.4. My previous statement stands - connection->timeout should not be NULL when waiting for data from the FTP server. BTW now that I re-read the original reporter's problem, I see that this is probably a different issue. The title just looked appropriate... ... The relevant backtrace within gnome-vfs2:
+ Trace 68571
Closing as OBSOLETE, since Nautilus does not use gnome-vfs anymore and this does not happen with 2.22.0.