nautilus ftp file transfer hangs in lucid

[Géza Búza]

Binary package hint: nautilus

1)
Description: Ubuntu 10.04 LTS
Release: 10.04

Description: Ubuntu 11.04
Release: 11.04

2)
nautilus version: 1:2.30.0-0ubuntu4; 1:2.32.2.1-0ubuntu13
gvfs version: 1.8.0-0ubuntu2

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.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: nautilus 1:2.30.0-0ubuntu4
ProcVersionSignature: Ubuntu 2.6.32-21.32-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-21-generic x86_64
Architecture: amd64
Date: Mon May 3 20:23:35 2010
ProcEnviron:
 PATH=(custom, user)
 LANG=hu_HU.utf8
 SHELL=/bin/bash
SourcePackage: nautilus

[Ginocolada (rhytmic)]

I tried gFTP 2.0.19 also freezes.

[Ginocolada (rhytmic)]

Resolved after the latest updates

[Géza Búza (medve)]

It is strange, because it did not work for me. It has the same problem in nautilus 1:2.30.1-0ubuntu1.

[Kjetil Thuen (kjetil-thuen)]

I'm still seing this too with the lucid-proposed repository enabled. Also, trying to manouver the ftp server in the ~/.gvfs directory produces lots of timeouts (but it does catch up on repeated tries).

[Ginocolada (rhytmic)]

The problem returned after the latest update seemed to fix it. Peculiar.

[Ldx (a-giove)]

I confirm the wrong behavior described: nautilus hangs during the transfer of MANY files via FTP, maybe exactly each time at the same point for each transfer:

First test (copy of ".thunderbird" folder via ftp): it hanged after few hundred bytes at each attempt, both via wireless and cable ethernet. Then I tried to ZIP all files and transfer the compressed package: no problem, it was transferred quickly and flawlessly (almost 1 GB in size).

Second test (copy of a subdir of Documents, about 28 MB): it hanged after about 8 MB at each attempt. Again, the zipped archive of the same files was transferred without problems.

System: Dell Latitude X1
1 GB RAM
Ubuntu 10.04 italian with all patches available just applied
Nautilus 2.30.1

Hope this helps.
Aldo

[tomaskCZ (tomaskcz1)]

The same problem - fiIe operation window hangs when trying to copy multiple files via nautilus ftp connection - only 'killall nautilus' would "close it".
Having nautilus 1:2.30.1-0ubuntu1, all patched up to date, so where is the patch released ?

[bobloblian (bob-computerisms)]

I am also seeing this problem on two different computers. I also tried this connecting to two different servers, proftp and vsftp, and behaviour is the same across both servers from both computers.
When dumping the traffic, I notice that traffic flows for a considerable time after the transfer freezes in the gui, and the last packets sent are from the client to the server. Both servers displayed in the logs that some portion of the number of files are transferred successfully, then it stops the transfer after some number of files. From the server's point of view, it appears that nautilus is only requesting a portion of the full transfer.
There does not seem to be a new version of nautilus available to me, including in the pre-release repo.
nautilus version is 1:2.30.1-0ubuntu1
If further information would be helpful, I would be glad to provide it.

[tomaskCZ (tomaskcz1)]

nobody probably cares about ftp these days ;)

[Thomas Field (thomasdfield)]

It seems to only happen when copying a directory with multiple subdirectories. The first subdirectory will copy, along with all it's files, then the second, and only one file. Then it freezes, and just as described, must be killed.

nautilus 1:2.30.1-0ubuntu1
gvfs-backends 1.6.1-0ubuntu1build1

[Pedro Villavicencio (pedro)]

This bug is an upstream one and it would be quite helpful if somebody experiencing it could send the bug the to the people writing the software. You can learn more about how to do this for various upstreams at https://wiki.ubuntu.com/Bugs/Upstream/GNOME . Thanks in advance!

[Ryan Jung (gradysghost)]

Confirmed. This problem also occurs when transferring the contents of a single directory with multiple files of any size. I have also experienced it when moving a single file (I had tried tar.gz-ing the directory that was having problems). At this point, I would say that this probably has no relationship to the type, quantity, or size of the files being transferred because I have reproduced the problems under more or less every combination I can think of. While it does appear to be somewhat random, it also appears to happen more often than not when transferring data.

I can also confirm that this happens when providing a specific IP address over a local network as well as when using DNS. My FTP server, for what it's worth, is using the default port, 21.

[[e-mail] (traderbam)]

Hi. I can reproduce this hang too. In fact, I first experienced it in 9.04 and reported it. But in 10.04 it is even worse! At least in 9.04 it was possible to kill the Nautilus process and stop the file transfer; now I cannot stop it. Nautilus becomes a Zombie process. Unplugging my LAN cable stopped it...until I plugged it back in again.

I do not understand why this fault does not have a HIGH priority. I would have expected any OS problem that requires a reboot to fix would be unacceptable to the Ubuntu developers.

My situation is a 10.04 Desktop 64-bit client with a OpenVPN tun tunnel to a 10.04 Server. I use the "Places" menu to create an SSH connection to the server and get a file browser window. I then drag and drop a 160MB CD iso file on to the server browser window. The File copy window appears but starts off with its progress bar 2/3 complete and remains there. The file transfer actually starts up and data is transferred over the LAN (as shown by System Monitor). But at the far end (viewed using a separate SSH terminal login) the file size seems to be way to big from the start and doesn't change. Nothing happens when I click the red X on the transfer window or try to close it. Killing the Nautilus process does not stop it and the process is shown as "zombie". I could not kill the vsftp process on the server (I assume this is the receiving process). I could find no way of stopping the determined LAN activity without restarting. Even then, the restart froze up during theboot and I had to pull the plug and start over.

THIS IS A SERIOUS PROBLEM for those of us managing remote servers and trying to do large file transfers.

Brian

[Pedro Villavicencio (pedro)]

could somebody get a backtrace of the hang so we can send the bug upstream? thanks in advance.

[tomaskCZ (tomaskcz1)]

which way Pedro, apport does nothing on that - should I use gdb on the whole nautilus ?
Nautilus is restarted automatically.

[Rihards (rihards-excite)]

The same problem for me. Actually this problem persists for very long time. For me it is easier to install ftp client and use it but anyway it is annoying.

[proletariat (proletariat)]

My transfers stop at about 10-30 percent every time i try to transfer multiples.
gFTP works okay but isn't the same as being able to edit files live through nautilus and gEdit, major slow down in productivity :(

my versions are:
Kernel 2.6.32-24-generic
Nautilus 2.30.1
Ubuntu Lucid Lynx 10.04
GDM 2.30.2

[Pedro Villavicencio (pedro)]

did somebody send this upstream ? the Ubuntu team doesn't have the resources to work on this right now, if you want it to be fixed the best way is to send it upstream. please read one of my previous comments to know how to do it, thanks.

[damaa (ma-soundz)]

have the same problem, posted it at gnome
https://bugzilla.gnome.org/show_bug.cgi?id=630348

[Christophe Van Reusel (christophevr)]

Hello same problem. When copy from to another ftp server. Using nautilus nautilus hangs after couple of files. Only happens when copy folder (with many or few files, with or whitout sub folders) This problem occurs from ubuntu 10.04. and it's also present on maverick. I do not now why they don't care about ftp anymore, as for a local network behind a good firewall, there is no problem for security. And ftp is still the fastest and most reliable way to copy large amount of data. Its also support's the file permission keep options which is important on linux and mac machines.

Thank's for having upstreamed the bug to gnome bugzilla.

This problem does not occur using gftp or fillezilla.

[Christophe Van Reusel (christophevr)]

Some additionall Info I also send it to bugzilla 630348

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.

[Omer Akram (om26er)]

Thanks for sending this bug upstream to gnome. I have made a comment there asking if any logs are required

[tomaskCZ (tomaskcz1)]

still present on 10.10, no change

[ngsupb (ngsupb)]

any updates on this issue? having the same problem too

[walther (walther-tw)]

I have this problem also, but only for ~3 days. Previously everything was working. The FTP server was not changed in any way, so I guess, there was an gvfs update?
Ubuntu 10.04, gvfs 1.6.1-ubuntu1build1, nautilus 1:2.30.1-0ubuntu1.1

Copying in terminal gives this:
~/.gvfs/FTP on 192.168.178.30/disk$ cp mydir ~/Desktop
cp: directory "mydir/" omitted

[Victor Vargas (kamus)]

This issue is still there in Ubuntu Natty Narwhal, according to some new reports (for instance 780084)
---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

[Sebastien Bacher (seb128)]

The bug there is confusing, it's a lucid bug but the recent duplicates seem to be about issues new in natty?

[Sebastien Bacher (seb128)]

bug #793143 for example state that 10.10 was working correctly, are the new bugs really a duplicate or a new bug in natty? Having a stacktrace would be useful to debug the issue

[Géza Búza (medve)]

Stack trace attached.

Ubuntu version:
Distributor ID: Ubuntu
Description: Ubuntu 11.04
Release: 11.04
Codename: natty

Package details:
libglib2.0-0 Version: 2.28.6-0ubuntu1
libgtk2.0-0 Version: 2.24.4-0ubuntu2
libgnomevfs2-0 Version: 1:2.24.4-0ubuntu4
gvfs Version: 1.8.0-0ubuntu2
libdbus-1-3 Version: 1.4.6-1ubuntu6

[Martin Braun (thesofty)]

On my opinion it seems to be a problem of gvfsd, especially gvfsd-ftp.
There is a bug ticket upstream related to gvfs and ftp chmod. https://bugzilla.gnome.org/show_bug.cgi?id=651729
It seems gvfs seems to have problems when the ftp server doesn't support chmod, which is common for security reasons. But it doesn't seem to work too, when the ftp server supports chmod. I tried it with my own ftp server. The problem was still there.
The upstream bug report contains a small patch to fix the problem. I tried the hack on my system with gvfs 1.8.2 (I used an Arch Linux setup for that test). For me that fix works fine.

I will leave an appropriate comment at the upstream bug message too.

[Sebastien Bacher (seb128)]

I've been browsing ftp.gnome.org with nautilus for a while, copying tarballs etc and got no issue

[Sergio Costas (rastersoft-gmail)]

I have that problem using FTP with a multimedia hard disk which uses bFTPd ( http://bftpd.sourceforge.net/ ). I don't have other FTP server to test it.

[Roman Yagodin (roman-yagodin)]

I have same problem in Ubuntu 11.04 x64 when connecting to Windows 2008 x64 host.
FTP in Nautilus was going wierd just after update from Ubuntu 10.10.

When I try to make a duplicate of file in a connected ftp folder with Ctrl-C / Ctrl-V, Nautilus return to computer:/// place or just close (besides, operation is completed). Copy several files / folder structure to an ftp site causes same issue, and really copied 1 file. Replacing files and cut/paste operations causes issues too.

Other clients (bareFTP, Filezilla) work fine. So I assume that gvfs-ftp support in Nautilus or gvfs-ftp is completely broken.

[Pavol Klačanský (pavolzetor-deactivatedaccount)]

I have oneiric and after copying file, it closes connection

[Subharo Bhikkhu (subharo)]

I'm using 11.04 Natty, and I can confirm this bug still happens.

It doesn't matter which particular ftp server is running on the server: wether it's wu-ftpd, pure-ftpd, wzdftpd or vsftpd, the bug happens in virtually exactly the same way. I've tried them all (thinking it might be their fault somehow).

And I can confirm that FileZilla can do bulk file transfers with no problems, connecting to those same servers.

So the problem clearly lies with Nautilus' VFS subsystem, as it handles bulk FTP file transfers.

Please fix this, since fast (i.e. faster than SFTP), easy file transfers on a LAN (where encrypting connection authentication isn't all that crucial, thanks to the protection from the internet by a firewall) are in my opinion *a basic office necessity*.

It would be a pity to have to rely on ancient, sometimes-inconsistent Microsoft-designed SMB networking (ie. creating file shares using nautilus-share), when an FTP daemon + avahi-daemon can do it better and faster, sticking to good-old TCP/IP.

[Wieger Wesselink (j-w-wesselink)]

Since this feature is rather important for me, I have installed Dolphin (from KDE) as a workaround. It's not the most elegant solution, but at least with Dolphin (S)FTP bulk transfer works fine!

[Subharo Bhikkhu (subharo)]

Another workaround which is more Gnome-esque (than Dolphin) is to install thunar, and libdesktop-agnostic-vfs-thunar.

The relevance to this bug is this: perhaps some developer (which I'm not) might want to look over the FTP-related code in libdesktop-agnostic-vfs-thunar, and perhaps use it somehow in Nautilus' corresponding VFS-related code.

Pardon me being a bit off-topic here, but for those who care about the getting fastest file transfer speed on their LAN, and less about tight-security-within-the-LAN, Thunar gave the fastest bulk FTP transfers I've ever seen (connecting to a pure-ftpd server), even 25% faster than doing the exact same bulk FTP copying within Filezilla. My test data was about 5300 files, most are small documents, 1.4 GB, transferred on a gigabit LAN). Compare FTP-within-Thunar to having the same data transferred using SMB (through Nautilus), and SSH/SFTP (through Nautilus) took 134% longer, and 349% longer, respectively. FTP-within-Thunar beat the pants off SMB-within-Nautilus and SFTP-within-Nautilus for speed, when it came to a larger set of small files.

Before flaming me, I feel it's highly relevant to mention these informal stats to underscore the point that in fixing this bug, greatly increased file transfer speed is won (within the LAN, where FTP still has usefulness) for Ubuntu as a whole (as installed by default). Like over twice as fast (even for large collections of tiny files, which usually transfer much more slowly than equivalent amount of larger files), compared to SMB file transfers!

[Chris Wulff (crwulff)]

The solution in the upstream post is actually almost right, but it is a little simpler than that. I've posted this upstream as well, but until they get around to it, it might be useful to include this patch in the ubuntu packages.

The section of code should just return TRUE instead of FALSE. Returning FALSE
means that the operation should be deferred in a thread (and the thread may not
run in this case until the job is destroyed so it crashes.) At least in my
system, marking the operation as failed doesn't disconnect the mount. It was
disconnected because the backend crashed.

From the backend header:

 These try_ calls should be fast and non-blocking, scheduling the i/o
 operations async (or on a thread) or reading from cache.
 Returning FALSE means "Can't do this now or async", which
 means the non-try_ version will be scheduled in a worker
 thread.

[Chris Wulff (crwulff)]

Note that this bug still exists in the latest Oneric Ocelot build of gvfs too (1.9.3) as it hasn't been fixed upstream either.

[Chris Wulff (crwulff)]

This is fixed upstream as of 1.9.4

[Subharo Bhikkhu (subharo)]

Chris: please pardon my lack of experience in this, but I noticed that on the "All software packages for Oneiric" page: http://packages.ubuntu.com/oneiric/allpackages
...that gfvs is listed as 1.9.3. Does this mean that this bug fix will probably only make it into Oneric + 1? In other words, is it too late for a bug fix such as this to get into Oneiric?

Perhaps a better question is this: when a bug like this gets marked as "Fix Released," does that generally mean the fix will only make it's way into one of two versions of Ubuntu in the Future (unless i'ts a security fix, in which case it would be released into the latest, current release of Ubuntu?)

[Chris Wulff (crwulff)]

It is up to the ubuntu devs whether they want to pull it in or back port it to older releases at this point in the release cycle. It could still potentially make it in, but it won't just automatically happen like it might earlier in the cycle. It is a simple enough fix that they might decide to toss it into the patch list.

[Subharo Bhikkhu (subharo)]

Oh Ubuntu Devs! Harken to my appeal! Have mercy! Please include gvfs 1.9.4 in Oneiric!

I feel that including this fix will deliver lots of "bang for the buck," because it will kill two birds with one stone, and thereby avoid these two "embarrassments":

1) Ubuntu not having any working graphical FTP client in it's default install (that I'm aware of), which many might find appalling and frustrating
2) If people try the obvious workaround of installing Thunar to get a working graphical FTP client (which seems to me a logical second choice, because Thunar can honour many of the same "Bookmarks" as in Nautilus), then they'll quickly and easily fall into Ubuntu Bug 751374 (https://bugs.launchpad.net/exo/+bug/751374), whereby they can't even open files in their Dash any more (nor from Firefox's "Downloads" window)! Although a fix for that bug is proposed (yet not yet included in Oneiric either), once one falls prey to that bug, it's is a relatively nasty and tedious problem to get out of (granted they even find their way to the bug report where a manual fix is detailed) just to get the Dash and Firefox to properly open files again.

In summary, I feel this bug should have a higher priority, because people might easily fall into Bug 751374 because of this bug.

[Martin Pitt (pitti)]

1.8.5 is in oneiric now, closing.

[Creak (romain-failliot)]

@Martin Pitt: "Fix Released" means that you'll consider including gvfs 1.9.4 in the next Oneiric release (11.10.1?)

[Martin Pitt (pitti)]

Creak [2011-09-08 8:03 -0000]:
> @Martin Pitt: "Fix Released" means that you'll consider including gvfs
> 1.9.4 in the next Oneiric release (11.10.1?)

No, it means that 1.9.5 is already _in_ oneiric, and thus will be in
11.10 :)

[Creak (romain-failliot)]

2011/9/8 Martin Pitt <email address hidden>
>
> No, it means that 1.9.5 is already _in_ oneiric, and thus will be in
> 11.10 :)
>

Ok cool! (It was because you wrote 1.8.5 in your previous post)

[Urban Purkat (urban-purkat)]

I still see this behavior in 11.10 with:
nautilus 1:3.2.1-0ubuntu3.1
gvfs 1.10.0-0ubuntu1

[Adam Niedling (krychek)]

I ran into this issue in Ubuntu 11.10 x64 while copying from the FTP server to my Ubuntu box. Please see attached video.
gvfs: 1.10.0-0ubuntu1
nautilus: 1:3.2.1-0ubuntu3.2
Linux: 3.0.0-15-generic
FTP server: OpenWRT Backfire (10.03.1, r29592), Linux 2.6.32.27, vsftpd 2.3.4-2

List of files I tried to copy: ./Sample/thuck-wtts-sample.avi thick-wtts.nfo thick-wtts.r00 ... thick-wtts.r57 thick-wtts.rar thick-wtts.sfv
The name of the directory: Welcome.to.the.Stukko.3333.HUN.DVDRip.XviD-Thuck
The size of the whole directory is approx 1.1 Gbytes. The rar files are approx 20 Mbytes. 64 files, 1 subdirectory.
(This material is of course a public domain home made footage)

I already reproduced this bug twice, copying only worked when I tried to copy the files themselves and not the whole directory. When I close all nautilus windows, the little copying bar still remains in the Launcher on the icon of nautilus indicating that some operation is still ongoing but nothing is actually happening.

I'm reopening this bug.

[Adam Niedling (krychek)]

I just realized I can't reopen this bug. :(

[Adam Niedling (krychek)]

The correct upstream bug is #630348