There is a bug in GVFS in Ubuntu 16.04. GVFS is the thing that Caja and Nautilus use to access/manipulate files. Currently in Ubuntu MATE 16.04 moving any more than a few files either completely freezes up the file manager or slows it down to a crawl. This bug is not limited to just Ubuntu MATE and Caja, Nautilus and other file managers derived from Nautilus are also affected.

Here is the procedure to follow to help us test the fix for a critical bug affecting Ubuntu MATE 16.04

Be aware that it's in the realm of possibilities that the proposed fix has a regression and therefore causes data loss. Before doing the test you should make sure you have a Backup. You should make sure you have a backup even if you're not doing the test.

This forum post hopefully will also give you a general idea of how to do SRU testing, since it's not an obvious process.

Though, I should mention; after executing caja -q, caja then would not open. A reboot was required. But, following that reboot, all was working well and the problem with file transfers has gone. They were cut and pasted in a couple of seconds.

Followed your instructions to test caja and as you said, it choked. Installed gvfs/xenial-proposed, reloaded caja, ran the test case again, and caja worked. I did not see the familiar file transfer box though. As Steve remarked, the transfer was quick, I did this several times to check it. Posted on Launchpad.

Edit: As a side effect, I noticed that this also eliminated a bug that I reported about lock screen.

After execution of caja -q caja did not open, so I opened it via the menu and copying of the files was done in less than a second, while before the upgrade it took forever.thanks for this upgrade, now my files transfer very much faster than before.

maybe i should ask this in some developer forum or not at all, but i'm curious.

"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."

can anyone explain the constructions "in linear time" and "in logarithmic time"? it sounds as though GVFS is running things as different threads or something, on the other hand it sounds like a simple case of insertions requiring a sort.

anyway i find "linear time" and "logarithmic time" to be odd usage, so i'm curious what gives, clues anyone?

I don't know these classes in particular but in data structures like binary trees (see https://en.wikipedia.org/wiki/Binary_tree), for example, you get "logarithmic time with respect to the number of elements" in some operations, because the data is split in levels each doubling in size the previous level. In other types of data structures it is necessary to go through all the data to find the point of operation, and that is said to requires "linear time with respect to the number of elements".

..."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."....

That might as well be in Martian to me. It would make as much sense. I aint no techno...

linear time: the duration of an operation scales proportionally with the number of items to be processed (e.g. if one item takes 2 seconds, 100 items would take 200 seconds)

logarithmic time: as you add items, the duration increases quickly initially, but then the curve flattens out, so you could have something like one item takes 2 seconds, two items take 3.5 seconds, three items take 4 seconds, 10 items take 4.2 seconds, 100 items take 4.4 seconds, etc. (these numbers are not mathematically correct, but I hope you get the idea)

FYI the bug cannot be reproduced with any currently supported version of Fedora that has been updated since April 2017. Fedora 25 is the oldest, so I tested with the MATE-Compiz build of that. The current build of gvfs for Fedora 25 is 1.30.4-1. If anyone is using an older EOL build of Fedora then maybe they will encounter this issue.

Because with CentOS 7.3 + MATE 1.16.2 from EPEL it can be reproduced. gvfs is build 1.22.4-8. So not really any big surprise.

I'm not sure any non-LTS distribution would still be affected by this issue unless they somehow overlooked upstream gvfs update releases