Description of problem: I've noticed that current nautilus have issues moving or copying a relatively large file (>10.MB) over different partitions. It actually starts the move (or the copying), then ETA begins to grow almost geometrically. Perfoming the same operation on the terminal doesn't have this problem, files get transfered asap (depending on the size). For example, while trying to copy a 35MB file, nautilus start showing the progress bar at ~1/4 of the way, then seems to get stuck as the ETA grows; copying from the terminal takes ~2 secs. Version-Release number of selected component (if applicable):nautilus-2.15.91-2.fc6 How reproducible: Always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: This happens with transfers between different partitions on the same disk, and also between an external usb disk and the system partition. If it matters, this is on a x86_64 installation.
I see this on i386 too.
I have a workaround in gnome-vfs upstream cvs, will be in the next release.(2.15.92)
Thanks, I'll be on look-out for it.
Should be fixed in gnome-vfs 2.15.92-1
This (or rather similar) is still present on file transfer over a network (albeit, on a slow network). I was trying to copy ~40MB file from home to work computer using nautilus, the transfer got to about a quarter of the way, after ~10mins before it hung. Clicking cancel doesn't stop it, had to kill nautilus. Doing 'scp' on the terminal takes ~16mins to complete the transfer. Let me know if you'll want me to open another bug for this.
Hmmm. This might still be the inotify issue we had before, but the workaround didn't help for network copies. Upstream does have a real fix for the inotify sleep, but that is not built in rawhide yet.
Did you copy from or to the local drive?
From the local drive.
Copying from a local drive to a remote share shouldn't cause the inotify problems seen before, so this is likely another problem. What exact type of share did you use? sftp:// ?
(In reply to comment #9) > What exact type of share did you use? sftp:// ? > Probably so. I created the connection with the 'ssh' option in connect to server.
I couldn't reproduce this with a local ssh copy. But this I think this is clearly a different issue. Could you open a different bug, ideally with a bit more information on your setup. Like, does this happen always? to all servers? etc