Bug#970228: nemo: Can no longer copy files

[Simon McVittie <smcv@debian.org>]

On Mon, 14 Sep 2020 at 09:09:34 +0100, Simon McVittie wrote:
> If you run it as `strace -efile nemo`, does the bug still happen? What
> output does it produce?

Ugh, I hadn't realised nemo is single-instance.

Please see whether you can reproduce this bug by installing libglib2.0-bin
and running

    gio copy /path/to/some/file /path/to/other/file

which is independent of any particular GUI file managers.

If that command exhibits the same bug, then try

    strace gio copy /path/to/some/file /path/to/other/file

and see what that produces.

Or try killing/exiting all nemo processes, or using a different GTK file
manager like thunar or nautilus. The goal is to get some output from
strace that only appears when you actually try (and presumably fail)
to copy the file, and refers specifically to the file you are trying to
copy. I'm a lot less interested in what happens during startup.

> I was unable to reproduce this bug: nemo copies files successfully from
> btrfs to btrfs for me.

I tried adding a ZFS volume to a test VM and I can't reproduce the bug
there either, with either nemo or `gio copy`.

On https://gitlab.gnome.org/GNOME/glib/-/issues/2189 there is some
suggestion that this might happen when copying from a read-only filesystem,
but I haven't been able to reproduce the bug that way either.

Are the filesystem you are copying from, and the filesystem you are
copying to, mounted with any non-default options? (For example, ro,
relatime or noatime.)

I have some vague ideas of places in GLib to try patching, but fixing a
bug without being able to reproduce it is a really slow process, so I
won't be able to prioritize it.

    smcv