Help test a critical bug fix in Ubuntu MATE 16.04

Development Discussion
1

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.

mate-gvfs.png850Ă—528 86.7 KB

The steps listed below are derived from the indication in the following bug report:

Feel free to read the bug report in order to understand the relation between the steps to verify and the bug report later on.

  • Update your Xenial install so it's up to date
  • Right click on your desktop, open a terminal, then create two folders:

mkdir T1 T2

  • Move into T1:

cd T1

  • Create 1024 random files in T1 using the command:
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
  • Open T1 in Caja, select all files using CTRL+A then cut them using CTRL+X
  • Open T2 in a new Caja window, then paste the files using CTRL+V
  • Observe the transfer slowing to a crawl and jamming.
  • Abort the operation, go to System -> Administration -> Software & Update, and in the last tab check "enable xenial-proposed"
  • In the terminal, update but DO NOT upgrade all packages after that, we'll only upgrade the packages we're testing (gvfs with dependencies)
sudo apt update
sudo apt install gvfs/xenial-proposed
  • Reload Caja:

caja -q

  • Run the Test case again.
  • Open T1 in Caja, select all files using CTRL+A then cut them using CTRL+X
  • Open T2 in a new Caja window, then paste the files using CTRL+V
  • Observe that the file transfer does not jam.
  • Report your findings on the bug report in Launchpad, you need a launchpad account to do this.
  • Go back to Software & Updates properties, last tab and un-check the option for xenial-proposed.
5 Likes
4

Hi Ouroumov

That’s fixed it.

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.

I’ve posted up on Launchapd

4 Likes
5

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.

3 Likes
6

The same for me, I do not have the account on launchpad but I have linked this post to other 4 linux forums.

3 Likes
7

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
8

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

3 Likes
9

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.

2 Likes
10

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
11

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
12

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.

3 Likes
13

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

2 Likes
14

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
15

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
16

:laughing:

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
17

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

God bless you. Maximuscore…:slight_smile:

2 Likes
19

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
20

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
21

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