GNOME Bugzilla – Bug 630348
nautilus ftp file transfer hangs
Last modified: 2013-06-08 23:49:16 UTC
Upstream from Ubuntu 10.04 LTS Binary package hint: nautilus 1) Description: Ubuntu 10.04 LTS Release: 10.04 2) nautilus version: 1:2.30.0-0ubuntu4 3) I tried to copy a directory with files from a server to my PC via FTP. I expected finishing the transfer. 4) The file transfer window appears and after a few percent of progress, it stops copying. I can not close the window, because when I click the cancel button, it goes to gray and nothing happens after that, so I have to kill the nautilus process. When I had tried to copy the same directory again, it stopped at the same percent of progress. Copying the same directory in nautilus via SFTP works flawlessly. Also copying that directory by gFTP works without problem. I did not see any error messages or entries in syslog related to this problem. more here: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/574693
could be related with bug 588187.
problem occurs also with ubuntu testing version 10 .10 nautilus 2.31.92 ubuntu's kernel 2.6.35-22
Hello I just studies the bug's 588187 could be related, but i'm not shure. I just found out that problem only occurs when : I select an folder(map) (with nautilus) on the ftp server, copy it. Then paste it to a place into my home folder (or other where My user name has write acces)but on my pc. When a select an folder + one or more other files, copy it . Then paste again to me it does work perfect. When a make connection with two different ftp server. Copy from server 1 paste to an writable place on server 2 The problem does NOT occur at all. So somehow it does lock up if I only select just a map(folder) and copy from server to myself, or from my self to server. Does not occur if I select just a map (folder) and copy from server 1 to server 2 using nautilus. Never occurs if a select a map(folder) + one or more file(s) this strange behaviour. But I gues a very small thing into source . This problem is from ubuntu 10.04 kernel 2.6.32-xx nautilus 2.30.0-xxx and higher kernels tested up to ubuntu 10.10 kernel 2.6.35-22 nautilus 2.31.92 This problem for me is not prestent on ubuntu 9.10 kernel 2.6.31-22 with nautilus 2.28.1 think a can't find more info then that. also nowhere any error report when problem occur.
Change the status to NEW
are there any type of logs required. people downstream would be happy to provide them.
Hello, I noticed missing info which maybe important to eventually track this problem. Test by me are performed on PC Gigibaty MB ep 45 extreme Intel duo 3.333 Ghz, 4Gb ddr2 ram 1066. Linux kernel amd64. The servers are all proftpd. The most important here is that the kernel 64 bits .(amd64) If other persons using 32 bits i386 kernels have the same problem it would be nice to report this as well. Also if they are not affected it's important to let it now. An extra test performed when I made server connection with Nautilus. The server is mounted in $home/.gvfs/ftpxxxx map When I connect with terminal. cd to the directory where server is mounted, and perform copy from a directory map with cp -f -r command user@pcname:~$ cd .gvfs user@pcname:~/.gvfs$ cd ftpxxx user@pcname:~/.gvfs/ftpxxx$ cp -r -f map $home/map It does work whitout problem. When I do extactly the same with copy and paste from nautilus browser it does NOT work. behaviour like mentionned before
I've got 32-bit ubuntu and it doesn't work.
Created attachment 178329 [details] backtrace This is in fact a gvfs issue. More like a design problem I'd say. Nautilus only triggers the issue but it exists and is waiting to be hit by something else. Please have a look at the attached backtrace. Frame #13 meets dbus_connection_dispatch() for the first time, processing a callback while the lock is held, leading to another nested sync call, resulting in second dbus_connection_dispatch() in frame #3. There we deadlock. From dbus-connection.c sources: > * Be careful about calling dbus_connection_dispatch() from inside a > * message handler, i.e. calling dbus_connection_dispatch() > * recursively. If threads have been initialized with a recursive > * mutex function, then this will not deadlock; however, it can > * certainly confuse your application. I'm thinking about possible ways to fix this, meanwhile please do not do any sync GIO calls within a callback handler.
*** Bug 637251 has been marked as a duplicate of this bug. ***
This issue is going to be addressed during porting to GDBus.
Hi guys, not sure how to get subscribed to this report without leaving a comment. having this issue for a long time already too.
Hi, I have what sounds like exactly the same thing, except with bluetooth obex transfers to a phone. In my case, the files don't have to be large (usually around 20K). I've tried to copy files with cp to the appropriate place in ~/.gvfs/. cp is able to create directories on the phone, but files fail with the message cp: cannot create regular file `/home/local/.gvfs/ddd/fff': Operation not supported. I've noticed that I can't come up with a single example of an incomplete file being transferred by nautilus, it seems to always hang after completing one file, and before starting the next. I also use nautilus to make ftp transfers of up to 2GB size files. And, while I don't get nautilus to hang during these ftp transfers, it does routinely stop with an error message after successfully transferring several files. I haven't noticed this problem with smb transfers. I currently have Gnome 2.32.1 Ubuntu 11.04; however, Ubuntu 10.10 had the same issues.
I think, the following bug message is closely related to this issue: Bug 651729 Maybe the fix, which is attached to that bug message, solves several problems, mentioned at this thread.
*** Bug 622033 has been marked as a duplicate of this bug. ***
(In reply to comment #13) > I think, the following bug message is closely related to this issue: > Bug 651729 > > Maybe the fix, which is attached to that bug message, solves several problems, > mentioned at this thread. Bug 651729 is a completely different issue. The GDBus port is being worked on in the "gdbus" git branch.
This is still an issue in Ubuntu 12.04. Please take a look at the downstream bug report which also includes a video of this problem: https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/932935
(In reply to comment #16) > This is still an issue in Ubuntu 12.04. Please take a look at the downstream > bug report which also includes a video of this problem: > https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/932935 Yes, that's correct, the gdbus port is still being worked on.
gdbus port has been merged, closing. Please report any regressions separately.
As always, I'm completely puzzled with those bug reports. I met EXACTLY the same symptoms as described, but in Ubuntu 12.04 and NOT 10.04. I have ABSOLUTELY NO CLUE how and when I can get the correction of this bug. I wonder how gbus can be related with a bug seemingly affecting only Nautilus. In https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/932935 I have devised a workaround for the problem I meet.