** Description changed:
Without these fixes, copying any more than a few files in several file
managers including but not limited to Nautilus and Caja either completely
freezes up the file manager (if this happens with a Cut and Paste, it destroys
user data by leaving files half moved) or slows it down to a crawl. These bugs
are not found when using the mv command in the terminal, which will copy the
files in a couple of seconds at maximum. This is a nightmare for people who
want to Cut and Paste a lot of files and who need to do it quickly.
Either find some files that you would be OK losing (or have a backup for) or
create the files yourself. You can run the following command to generate 1024
empty 1 MB files (do this in an empty directory, where you have at least 1 GB
of free space), which is a valid way to reproduce this bug:
i=1 && while [ $i -lt 1025 ]; do dd if=/dev/zero of=$i bs=4k
iflag=fullblock,count_bytes count=1M; i=$[$i+1]; done
(Credit to https://stackoverflow.com/a/11779492/4123313 and
http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_09_02.html - also,
neither truncate or fallocate are used because the bug cannot be
reproduced when using those tools, my theory is that with dd it actually
writes the zeroes, with those tools, they say they wrote the zeroes to
the filesystems but it seems they actually didn't (something along the
lines of that), although I could be wrong)
If you open Nautilus or Caja, and Cut and Paste these 1024 files
somewhere else, the transfer will slow to a crawl, and in one instance
where I tried this with 1024 empty 512 MB files, Nautilus actually
crashed. This is very different to using mv in the terminal before doing
it in the file manager, which transfers these files flawlessly.
Once this fix is applied and I recreate these files, the transfer in
Nautilus and Caja is almost as fast as using mv (I'd say within a
second), which is what should happen.
[Breakdown of the patches and the regression potential for each]
- First, I'd like to thank levien for providing the bug report and the patch
links to fix this. Without that, it would have been a bit more work to hunt
down which patches are applicable.
+ First, I'd like to thank levien for providing the patch links to fix this.
Without that, it would have been a bit more work to hunt down which patches are
Patch Description: The metabuilder stores files and data in sorted lists. An
insertion into a sorted list is done in linear time, which highly affects
efficiency. In order to fix this, use GSequence instead which does insertion
and deletion in logarithmic time.
This patch is in here because it helps with a large amount of files.
Regardless if the files are 1 MB or 10 GB, the sorting of the files to
be moved/copied is inefficient. This addresses part of the problem by
making sure large amount of files can be dealt with efficiently. The
regression potential for this is low, and the only case that I can see
where a package would regress is a file manager that depends on (not
100% on this theory but it's a possibility) monitoring the status of the
list at a given time, and is incompatible with using GSequence. In this
case, the package would have something peculiar hardcoded, and would
most likely have an upstream fix that could be backported because this
fix is in the gvfs release that is already in 17.04 and later (so they
should have fixed it already). I can't think of a package that does this
(from what I can tell, it's not sane code if it isn't compatible with
this change) but if something does regress, it should be trivial to fix.
Patch Description: Some of the lists used by the metabuilder have items
appended to them. Appending to a list is done in linear time and this highly
affects efficiency. In order to fix this, use GQueue which supports appending
in constant time.
This patch is extremely similar in function to the last one, but this
one addresses items appended to a list instead of files and data in
sorted lists. As such, the regression potential is similar (low) because
it would involve a package hardcoding some things that are incompatible
with GQueue, and would most likely have an upstream fix that could be
backported because this fix is in the gvfs release that is already in
17.04 and later (so they should have fixed it already). I can't think of
a package that does this (from what I can tell, it's not sane code if it
isn't compatible with this change) but if something does regress, it
should be trivial to fix.
Patch Description: The file->children condition is always true at this point,
child->children should be there instead in order to speed up processing. This
fix doesn't affect the functionality, it just slightly improves processing.
This is a trivial iteration on top of the other two patches that
improves performance while not affecting functionality. It just seems to
eliminate an unnecessary step when executing the file by putting
child->children there instead as it improves processing time. The
regression potential is low because all of the variables already exist
and the patch would have been likely been integrated in one of the other
two if they had noticed the performance enhancement. Also, it doesn't
affect functionality, so a regression seems unlikely because if one
exists it would be in one of the other patches.
Patch Description: g_dbus_connection_flush_sync causes troubles in certain
cases when using multiple threads. The problem occurs when there are ongoing
gvfs_metadata_call_set_sync calls. It blocks threads e.g. when moving files
over Nautilus. Nautilus freezes sometimes due to it. Use sync methods instead
of flushing dbus. I don't see any significant slowdown when using sync methods
instead of the flushing according to my testing. It fixes hangs in Nautilus and
moving in Nautilus is almost instant again.
This patch fixes the Nautilus crashes.
It helps fix the problems introduced in some cases when using mutliple
threads are being used. One comment that is removed alongside the code
it is noting (this stood out to me) is the following:
/* flush the call with the expense of sending all queued messages on the
It shows that when initially writing this, care wasn't taken to ensure
that it would be useful when there is a large amount of queued calls,
i.e. in the case of this bug. If the user does not have enough memory
(which is my theory about what the issue was when I reproduced this on
my hardware, it showed an error message something along the lines of
"Out of Memory"), Nautilus will stop and fail to continue the operation.
This takes care to make sure this is never the case, and uses
gvfs_metadata_call_remove_sync instead of flushing dbus, which is much
more efficient, and helps make sure that given a large amount of files,
it will not crash.
- In any case, these patches are tracked in upstream bug 757747 (
https://bugzilla.gnome.org/show_bug.cgi?id=757747 ), and if regressions in this
code are found, it will likely be noted there.
+ In any case, these patches are tracked in upstream bug 757747 (
+ https://bugzilla.gnome.org/show_bug.cgi?id=757747 ), and if regressions
+ in this code are found, it will likely be noted there.
With Nautilus, I navigated to a folder that contained about 2,000 gif files.
I selected all of them
I cut with Ctrl+X
I navigated to another folder
I pasted with Ctrl+V
=> A popup window appeared saying "Preparing to move N files", and it got
stuck there forever.
Nautilus stopped responding. I waited half an hour, then I had to kill it.
Actually some of the files were moved. Which is the worst thing that
I tried again with the remaining files and it happened again!! It's
I suspect it has to do with displaying the previews of a big number of
files. Nautilus becomes completely unmanageable whenever you open
folders with lots of files. Maximum priority should be given to the UI
and actual operations; displaying of the previews should be done in the
background and should never, ever slow down user operations the
slightest bit. Seems pretty obvious.
Also note that 2000 is not even that much. Actually it's very few files.
DistroRelease: Ubuntu 12.10
Package: nautilus 1:3.5.90.really.3.4.2-0ubuntu4.2
ProcVersionSignature: Ubuntu 3.5.0-25.38-generic 188.8.131.52
Uname: Linux 3.5.0-25-generic i686
Date: Tue Feb 26 18:23:52 2013
- b'org.gnome.nautilus.window-state' b'geometry' b"'1312x713+64+71'"
- b'org.gnome.nautilus.window-state' b'sidebar-width' b'180'
- b'org.gnome.nautilus.window-state' b'start-with-status-bar' b'true'
+ b'org.gnome.nautilus.window-state' b'geometry' b"'1312x713+64+71'"
+ b'org.gnome.nautilus.window-state' b'sidebar-width' b'180'
+ b'org.gnome.nautilus.window-state' b'start-with-status-bar' b'true'
InstallationDate: Installed on 2010-06-23 (979 days ago)
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100429)
- PATH=(custom, no user)
+ PATH=(custom, no user)
UpgradeStatus: Upgraded to quantal on 2013-01-13 (44 days ago)
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
[SRU] cut-n-paste move files got stuck forever
To manage notifications about this bug go to:
ubuntu-bugs mailing list