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.
3 Likes
Yup. Fixed the issue on the one machine that I tested. will have to implement on the others.
3 Likes
Thank you everyone who took the time to test this and post your findings on Launchpad! 
️
Anyone else who can help validate this fix would be welcome.
2 Likes
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 ?
1 Like
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.
2 Likes
Better late than never. 
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.
3 Likes
Tested yesterday at work and now at home, both UM 16.04 worked fine now!
2 Likes
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?
1 Like
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”.
3 Likes
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
2 Likes
-
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)
6 Likes
God bless you. Maximuscore…
2 Likes
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
2 Likes
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
1 Like
The following:
ouroumov@Edge:~$ 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.
1 Like
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.
2 Likes
Thanks, let us know when you know more.
1 Like
I used Caja for the test NOT Thunar.
1 Like
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 ??
1 Like
Are you testing the updated package?
1 Like