Help test a critical bug fix in Ubuntu MATE 16.04



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.


Yup. Fixed the issue on the one machine that I tested. will have to implement on the others.


Thank you everyone who took the time to test this and post your findings on Launchpad! :heart:

Anyone else who can help validate this fix would be welcome.


I use Thunar as my FM and it does not have any problems.

So will there be fix in the future for Caja that will come thru Software Updates ?


Well it’s kind of the point of what we’re doing here.
There’s a fix, we need people to help test that fix so it lands in the LTS.


Better late than never. :relaxed:

I’ll note it fixes the problem in both the normal MATE 1.12.1 as well as the MATE 1.16.2 PPA.

I removed xenial-proposed repo and assume the gvfs packages will be happy going forward and probably sync with a future update.
EDIT: Duh! I see you have this covered. Good idea.


Tested yesterday at work and now at home, both UM 16.04 worked fine now!


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, 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”.



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

Either that or I am getting old…hahaha

  • 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)


God bless you. Maximuscore…:slight_smile:


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


I had NO problem cutting and pasting those 1024 files.

Can see any bug on my system ?

Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial


The following:

[email protected]:~$ apt-cache depends thunar | grep gvfs
  Recommends: gvfs

Makes me think that thunar does not rely on gvfs for core functions such as moving files.
If that’s the case thunar wouldn’t be affected by this issue.


Something new to report.

Tonight, I tried to copy, via Caja, around 3.5 GB spread over about 10 video files from an internal hard drive to an external usb. It locked about a third of the way through the operation. repeated attempts produced the same outcome

This is after installing the fix.

I have not had time to investigate further as I had to go out and willnpt be back at my machine till in the morning. So, I cannot currently say if this is related to the fix, in spite of the fix, or an unrelated issue with the files themselves or, even, the USB. But, thought I should mention it.


Thanks, let us know when you know more.


I used Caja for the test NOT Thunar.


I cut and pasted using Caja, 44 files of 244 Mb from flash drive to hard drive.

No issues.

To be frank, I see no bugs ??


Are you testing the updated package?