Workaround within. I am surprised to upgrade to 12.04 with updates up to 13.06 and to meet this very serious problem reported 12.02 that did not exist with 10.04.
In my mind, a bug report system should contain not only a Bug description and a Bug Discussion sections but also a Bug solution section where the user can find in everybody's terms what he must do to solve the problem in the LTS system he is running (and not another one). I am surprised that this doesn't seem to be Canonical's view. In consequence, I have written the summary of what would have remained hidden in here as an update to Bug Description to serve as a Bug Solution/Workaround. After upgrading to 12.04 updated 13.06, I met the bug described here. Typically, I was unable to download a folder from the FTP server (make a backup). I had the idea to work with links instead of canonical (ahem) names. ln -sfT ~/.gvfs/"FTP as username on hostname" my.local.alias And there went the folder copy happily to that link. Even made the copy test both ways simultaneously. Well, there were a few files on which the Copy stopped with a error. But that's because my server makes frequent size limits, aborts, timeouts and such. File Copy should have a retry option and I retried manually. Now I still have to see if another PITA remains. Sometimes, the information obtained from a subsequetly opened FTP connection predates what's supposed to be accomplished on the first connection (race condition), such as an application creating a file and then trying to rename it and getting a "does not exist" [yet] result. Another problem is that opening the canonical name opens Firefox instead of Nautilus. Also worked around with the symbolic link. > nobody probably cares about ftp these days ;) Oh yes. Think twice. It's often the only way to access a free server and you shouldn't tell them that gvfs-ftp and Gigolo make it as easy as anything. > it would be quite helpful if somebody experiencing it could send the bug the > to the people writing the software. Ubuntu users should not be requested to know where Canonical gets its software and to do that. (even a triager once sent me to the wrong place) This bug report should be peered with an "upstream" bug by Canonical so that everybody can contribute from Launchpad without the need to make dozens of OpenIDless other subscriptions. And so would the Ubuntu users get all the Ubuntu information in the Ubuntu database. I've seen attempts to peer BugDBx with BugDBy. That's a N*N effort. Maybe create a central hub and make it a N effort? > Adam: You’re right, nautilus doesn’t seem to remember the password. Once I > unmounted the FTP share, I have to re-type the password if I want to mount it > again. But this really seems to be a different bug. Use Gigolo, it does it, and be happy. Made in Belgium, with chocolate and beer ;-) Enjoy! ** Description changed: + Update by André aka Papou. Workaround. See comment #26 for details. + I had the idea to work with links instead of canonical (ahem) names. + ln -sfT ~/.gvfs/"FTP as username on hostname" my.local.alias + And there went the folder copies happily to and from that my.local.alias link. + Working with an alias and Gigolo has other advantages. + --- EOU --- + This report is basically the same as bug #574693 but it is already closed as fixed and won't be reopened. 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-16-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 three times, copying only worked when I tried to copy the files themselves and not the whole directory. The operation always stops around 20 megabytes. 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. ProblemType: Bug DistroRelease: Ubuntu 11.10 Package: gvfs 1.10.0-0ubuntu1 ProcVersionSignature: Ubuntu 3.0.0-16.28-generic 3.0.17 Uname: Linux 3.0.0-16-generic x86_64 NonfreeKernelModules: wl ApportVersion: 1.23-0ubuntu4 Architecture: amd64 CheckboxSubmission: e2c1dd7c516ed88e0de43a227ceb28c1 CheckboxSystem: 2954e74ba17fb0e37fc942cd1d9fab4e Date: Wed Feb 15 18:35:20 2012 InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012) SourcePackage: gvfs UpgradeStatus: No upgrade log present (probably fresh install) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/932935 Title: nautilus ftp file transfer hangs when transferring directories To manage notifications about this bug go to: https://bugs.launchpad.net/gvfs/+bug/932935/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
