Hang on connection to FTP, with cancel

[Corey Burger]

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

[Corey Burger (corey.burger)]

Reported upstream:
http://bugzilla.gnome.org/show_bug.cgi?id=311708

[Sebastien Bacher (seb128)]

Thanks for your bug. What version of nautilus are you using? How do you create
the connection? It should use the gnome-keyring to store the password. Does it
freeze every time?

[Corey Burger (corey.burger)]

2.11.90
Places--connect to server
didn't choose gnome keyring
and it freezes everytime

[Gary Coady (garycoady)]

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...

[Sebastien Bacher (seb128)]

Gary, I've copied your comment upstream. What version of Ubuntu do you use? What did you do exactly to get the hang? Cancel button works fine on my box and nautilus doesn't freeze

[Gary Coady (garycoady)]

Sebastien Bacher wrote:
> Gary, I've copied your comment upstream. What version of Ubuntu do you use? What did you do exactly to get the hang? Cancel button works fine on my box and nautilus doesn't freeze

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.

[Gary Coady (garycoady)]

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...

[Gary Coady (garycoady)]

The relevant backtrace within gnome-vfs2:
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb753e0c1 in ___newselect_nocancel () from /lib/tls/i686/cmov/libc.so.6
#2 0xb79b355b in gnome_vfs_inet_connection_read (connection=0x84e03b0,
    buffer=0x84e05a4, bytes=<value optimized out>, bytes_read=0xb4abfd20,
    cancellation=0x0) at gnome-vfs-inet-connection.c:355
#3 0xb79c36f7 in gnome_vfs_socket_read (socket=0x8303690, buffer=0x0,
    bytes=4096, bytes_read=0xb4abfd20, cancellation=0x0)
    at gnome-vfs-socket.c:146
#4 0xb79c2d92 in refill_input_buffer (socket_buffer=0x84e05a0,
    cancellation=0x0) at gnome-vfs-socket-buffer.c:140
#5 0xb79c2ec5 in gnome_vfs_socket_buffer_read (socket_buffer=0xfffffdfe,
    buffer=0xb4000470, bytes=4096, bytes_read=0xb4abfdc0, cancellation=0x0)
    at gnome-vfs-socket-buffer.c:200
#6 0xb68d4f34 in get_response (conn=0x834dc48, cancellation=0x0)
    at ftp-method.c:403
#7 0xb68d7302 in do_close (method=0xb68d92e0, method_handle=0x834dc48,
    context=0xfffffdfe) at ftp-method.c:1877
#8 0xb79b2d4b in _gnome_vfs_handle_do_close (handle=0x84b85d0,
    context=0xfffffdfe) at gnome-vfs-handle.c:117
#9 0xb79ab094 in gnome_vfs_close_cancellable (handle=0x84b85d0, context=0x0)
    at gnome-vfs-cancellable-ops.c:107
#10 0xb79c0ef3 in gnome_vfs_close (handle=0xfffffdfe) at gnome-vfs-ops.c:192
#11 0xb79ced78 in copy_file (info=0x8638e88, source_uri=0x8638d30,
    target_uri=0x86a5518, xfer_options=GNOME_VFS_XFER_RECURSIVE,
    error_mode=0xb4ac0140, overwrite_mode=0xb4ac0004, progress=0xb4ac01e0,
    skip=0xb4abff40) at gnome-vfs-xfer.c:1509

[Sebastien Bacher (seb128)]

I've forwarded your comments upstream. Do you think a part of the issue is due to vsftpd?

[Diego Foglino (biker84)]

I have the same problem when I try to transfer file whit FTP protocol.
I follow the procedure in the first post and I have the same problem.

[Nick Manley (darkhack)]

I'm using the latest version of feisty and I am having this problem as well. It sometimes happens even when transferring small files (less than 5kb). It would appear as though there is no timeout for FTP connections. I don't even have to click cancel though. I just have to be transferring items via FTP and if the connection somehow drops, it will hang.

[Yann Rouillard (yann-pleiades)]

I don't reproduce this bug on gutsy. Do you still have this problem ?

[Sebastien Bacher (seb128)]

That should be fixed in hardy now where nautilus uses gvfs, feel free to reopen if you still have a similar issue there though

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

Do not just set two years old bugs to confirmed without any comment. Open a new bug.