[xubuntu-users] Slow opening folders on Xubuntu 20.04

[Phil Staub]

Hi Ralf:

Sorry again for the delay. Although I'm subscribed to the xubuntu-users list, I didn't receive either of your replies. But that's off topic, so I'll get back to the subject at hand.

    On Fri, 5 Jun 2020 22:19:08 -0400, Phil Staub wrote:
    >>/Just for testing purpose install spacefm/spacefm-gtk3. It's a very />>/customizable file browser that doesn't have a dependency to GNOMEish />>/bloatware helpers such as gvfs. />>//>>/sudo apt update />>/sudo apt install spacefm-gtk3 />>//>>/Do you experience the same delay issue when using spacefm? />//>/Interesting. No delay using spacefm. It should be noted that although />/I installed spacefm-gtk3, I only found spacefm executable. /
    Hi Phil,

    that's correct, the executable is always named 'spacefm', the packages
    just provide a version compiled against gtk2 and another compiled
    against gtk3.

    >>/You can remove spacefm by running />>//>>/sudo apt purge spacefm-gtk3 />//>/For the time being, I'll leave it installed, but it WOULD be good to />/know what causes the delay with Thunar and Nemo. /

I've got a bit of a problem here in that I now can't reproduce the delay.

What I've done:

1. Installed spacefm-gtk3
2. Set spacefm as my preferred file manager
3. Double-clicked several folders on my desktop. No delay on any of them.
4. Set Nemo back as my preferred file manager
5. Double-clicked several folders on my desktop. Now there was no delay,
6. Uninstalled spacefm
7. Reboot/login
8. Still no delay.

It should be noted that there were two events that happened after I installed spacefm. I suspect that either one of these might have been a contributing factor in the delay:

1. I had an ext4-formatted blank thumb drive in a usb port. I rebooted (for other reasons), and had to unplug the thumb drive to get the machine to boot. If fuse were somehow involved (and thus gvfs) I suppose this could have caused an issue.

2. I had some partitions mounted from another machine. Two NFS mounts and two CIFS mounts. The machine these partitions resided on started acting strangely. Running very slow, though the load average didn't seem excessive. I didn't see anything obvious causing this, so I rebooted the server. Even the reboot was acting strangely. I actually had to make several attempts to get it to reboot from the command line. Once it rebooted, the server seemed to be fine. I also didn't see anything particularly troublesome in the logs.

So this might be one of those issues that a reboot clears, but the purist in me would really like to know the underlying mechanism of the failure. Well, unless it happens again, I'll just assume some process got hung or swamped.

Once again, thanks for your comments.

Phil

      GVFS is still a possible culprit. For testing purpose you could install an
    empty dummy package, so you don't break hard dependencies against gvfs, but
    you could test, if running Thunar or Nemo doesn't suffer from a delay anymore.

    Build and install a dummy package and remove gvfs dependencies:

    $ sudo apt update && sudo apt install equivs
    $ mkdir dummy-package
    $ cd dummy-package/
    $ echo "Package: gvfs" > gvfs
    $ echo "Version: 2020:06-06-test" >> gvfs
    $ echo "Maintainer: Phil Staub <phil at staub.us  <https://lists.ubuntu.com/mailman/listinfo/xubuntu-users>>" >> gvfs
    $ echo "Architecture: all" >> gvfs
    $ echo "Description: Dummy package" >> gvfs
    $ equivs-build gvfs
    $ sudo apt install ./gvfs_06-06-test_all.deb
    $ sudo apt remove gvfs-common gvfs-daemons gvfs-libs

    You can downgrade to gvfs, IOW reinstall gvfs from Ubuntu repositories and
    install it's dependencies by running:

    $ sudo apt update && sudo apt install gvfs=$(apt-cache show gvfs | grep Version:\ 1 | head -1 | cut -d" " -f2)

    Regards,
    Ralf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/xubuntu-users/attachments/20200607/b81044b4/attachment.html>