Bug#970228: nemo: Can no longer copy files
Should I mention again that I have this problem with Nautilus and Thunar over Samba, with Xfce on sid, and there's not a trace of ZFS anywhere in my network? It isn't just affecting ZFS. -- Joe
Bug#970228: nemo: Can no longer copy files
On Tue, 15 Sep 2020 at 09:43:28 +0200, Holger Schröder wrote: > I have found the reason for this. I had already set atime=off in my > zpools some time ago. I tried to switch it on again (zfs set atime=on > $pool). And the problem disappeared and everything works again. Thanks, I can now reproduce this with "zfs set atime=on pool1" and "gio copy x y" where x is an empty file on the ZFS volume. I had previously tried "mount -o remount,noatime", which would have worked with other filesystems, but apparently that doesn't work with ZFS. > why the newer glib can't handle it I don't know Because it uses a newer file-information API that indicates when information from the filesystem is meaningless (like the atime on a noatime filesystem), and the code to use that API assumes that all the information traditionally provided by stat() is meaningful, which is a wrong assumption on a noatime ZFS volume. smcv
Bug#970228: nemo: Can no longer copy files
I have found the reason for this. I had already set atime=off in my zpools some time ago. I tried to switch it on again (zfs set atime=on $pool). And the problem disappeared and everything works again. But why the newer glib can't handle it I don't know. I hope this helps to find the error. Holger...
Bug#970228: nemo: Can no longer copy files
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
Bug#970228: nemo: Can no longer copy files
On Mon, 14 Sep 2020 12:16:05 +0200 =?UTF-8?Q?Holger_Schr=c3=b6der?= wrote: > Am 14.09.20 um 11:31 schrieb Simon McVittie: > > Control: retitle -1 nemo: Can no longer copy files on zfs since > > GLib 2.66.x Control: retitle 970263 glib2.0: nemo can no longer > > copy files on zfs since 2.66.x > > > > On Mon, 14 Sep 2020 at 11:19:04 +0200, Holger Schröder wrote: > >> I have zfs only. > > zfs implemented how? The zfs-dkms kernel module, or zfs-fuse? > > > zfs-dkms, zfs-initramfs (zfs rootfs) > > https://github.com/openzfs/zfs > > As said, there is only zfs and no other file system. > > > dpkg -l | grep zfs > ii libzfs2linux 0.8.4-2 amd64 > OpenZFS filesystem library for Linux > ii zfs-dkms 0.8.4-2 all OpenZFS > filesystem kernel modules for Linux > ii zfs-initramfs 0.8.4-2 all > OpenZFS root filesystem capabilities for Linux - initramfs > ii zfsutils-linux 0.8.4-2 amd64 > command-line tools to manage OpenZFS filesystems > I'm seeing this with Nautilus and Thunar on sid. Source and destination on Samba shares on ext4. No problem copying on local hard drive. Running Nautilus from the command line makes no difference. First noticed today, was OK three days ago. -- Joe
Bug#970228: nemo: Can no longer copy files
Further info: No problem copying the same file when logged into the host of the shares, using mc (no GUI). No problem copying the file via Samba from another workstation using Unison. Other people are not using Samba, so presumably the problem isn't with Samba itself but the interface between graphical file managers and Samba, and between them and zfs. -- Joe
Bug#970228: nemo: Can no longer copy files
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?
>From the strace log sent by private email due to containing personal
filenames etc., statx() is basically functional on the bug reporter's
system:
openat(AT_FDCWD, "[redacted]", O_RDONLY) = 16
statx(16, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_TYPE,
{stx_mask=STATX_TYPE|STATX_MODE|STATX_NLINK|STATX_UID|STATX_GID|
STATX_MTIME|STATX_CTIME|STATX_INO|STATX_SIZE|STATX_BLOCKS|0x1000,
stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=[redacted], ...}) = 0
but I think we might be hitting this:
retval = statx (dirfd, pathname, flags, mask, stat_buf);
if (retval == 0 && (stat_buf->stx_mask & mask_required) != mask_required)
{
/* Not all required fields could be returned. */
errno = ERANGE;
return -1;
}
It looks like the STATX_ATIME and STATX_BTIME are not coming back from the
kernel, and STATX_ATIME is on GLib's "required" list (for feature parity
with plain stat(), which always puts *something* in struct stat->st_atime,
even if it's nonsense.)
Additionally, the kernel is telling us the STATX_MNT_ID (0x1000), which
we didn't even ask for, but presumably it has that information so easily
available that it might as well tell us.
Holger, do you happen to know whether ZFS implements last-accessed time
(st_atime) like e.g. ext4 and btrfs do, or does it not have that concept?
says
* Items in STATX_BASIC_STATS may be marked unavailable on return, but they
* will have values installed for compatibility purposes so that stat() and
* co. can be emulated in userspace.
so perhaps GLib shouldn't be checking against mask_required in the way it
is here.
I'll try to get a ZFS filesystem on a test VM to reproduce this.
smcv
Bug#970228: nemo: Can no longer copy files
I have tested Thunar from XFCE, same problem. ...
Bug#970228: nemo: Can no longer copy files
Am 14.09.20 um 11:31 schrieb Simon McVittie: Control: retitle -1 nemo: Can no longer copy files on zfs since GLib 2.66.x Control: retitle 970263 glib2.0: nemo can no longer copy files on zfs since 2.66.x On Mon, 14 Sep 2020 at 11:19:04 +0200, Holger Schröder wrote: I have zfs only. zfs implemented how? The zfs-dkms kernel module, or zfs-fuse? zfs-dkms, zfs-initramfs (zfs rootfs) https://github.com/openzfs/zfs As said, there is only zfs and no other file system. dpkg -l | grep zfs ii libzfs2linux 0.8.4-2 amd64 OpenZFS filesystem library for Linux ii zfs-dkms 0.8.4-2 all OpenZFS filesystem kernel modules for Linux ii zfs-initramfs 0.8.4-2 all OpenZFS root filesystem capabilities for Linux - initramfs ii zfsutils-linux 0.8.4-2 amd64 command-line tools to manage OpenZFS filesystems ...
Bug#970228: nemo: Can no longer copy files
Control: retitle -1 nemo: Can no longer copy files on zfs since GLib 2.66.x Control: retitle 970263 glib2.0: nemo can no longer copy files on zfs since 2.66.x On Mon, 14 Sep 2020 at 11:19:04 +0200, Holger Schröder wrote: > I have zfs only. zfs implemented how? The zfs-dkms kernel module, or zfs-fuse? I suspect this bug might be specific to zfs, or perhaps specific to one of the implementations of zfs - I wouldn't be surprised if GLib's new statx()-based file metadata handling works fine with in-tree filesystems like ext4 and btrfs but behaves oddly in some way with out-of-tree zfs. smcv
Bug#970228: nemo: Can no longer copy files
Am 14.09.20 um 10:09 schrieb Simon McVittie: Control: tags -1 + moreinfo unreproducible On Sun, 13 Sep 2020 at 11:26:46 +0200, Holger Schröder wrote: Can no longer copy files with Nemo. error when getting information for file descriptor numerical: result out of range What filesystem (ext4? btrfs? FAT? NTFS? ...) are you copying from? What filesystem are you copying to? I have zfs only. If you run nemo from a terminal (xterm, gnome-terminal or equivalent), does the bug still happen? Terminal no error output. If you run it as `strace -efile nemo`, does the bug still happen? What output does it produce? I will give it later tonight when I am at home. ...
Bug#970228: nemo: Can no longer copy files
Control: tags -1 + moreinfo unreproducible
On Sun, 13 Sep 2020 at 11:26:46 +0200, Holger Schröder wrote:
> Can no longer copy files with Nemo.
>
> error when getting information for file descriptor numerical: result out of
> range
What filesystem (ext4? btrfs? FAT? NTFS? ...) are you copying from?
What filesystem are you copying to?
If you run nemo from a terminal (xterm, gnome-terminal or equivalent),
does the bug still happen?
If you run it as `strace -efile nemo`, does the bug still happen? What
output does it produce?
I was unable to reproduce this bug: nemo copies files successfully from
btrfs to btrfs for me.
Please copy and paste messages exactly, and do not rephrase them: they
are a useful tool to find what is happening.
I think this is probably a problem with GLib's new statx() support, in
gio/glocalfile.h (which is working for me, but apparently not for you).
On Mon, 14 Sep 2020 at 07:35:27 +0900, Norbert Preining wrote:
> reassign -1 libglib2.0-0
When reassigning bugs, please remember to Cc the maintainers
of the new package via their ${package}@packages.debian.org or
${package}@tracker.debian.org address.
Thanks,
smcv
Bug#970228: nemo: Can no longer copy files
clone 970228 -1 reassign -1 libglib2.0-0 affects -1 nemo thanks On Sun, 13 Sep 2020, Holger Schröder wrote: > I think this is related to the new glib (2.66.0-1) being in unstable. > downgrade from testing (2.64.4-1) solves the problem. Thanks for the info, cloning and reassigning accordingly. Norbert -- PREINING Norbert https://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#970228: nemo: Can no longer copy files
I think this is related to the new glib (2.66.0-1) being in unstable. downgrade from testing (2.64.4-1) solves the problem. ...
Bug#970228: nemo: Can no longer copy files
Package: nemo Version: 4.6.5-1 Severity: normal Can no longer copy files with Nemo. error when getting information for file descriptor numerical: result out of range Cheers Holger... -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages nemo depends on: ii cinnamon-desktop-data 4.6.4-1 ii desktop-file-utils 0.26-1 ii gsettings-desktop-schemas 3.36.1-1 ii gvfs 1.44.1-1+b1 ii libatk1.0-02.36.0-2 ii libc6 2.31-3 ii libcairo-gobject2 1.16.0-4 ii libcairo2 1.16.0-4 ii libcinnamon-desktop4 4.6.4-1 ii libexempi8 2.5.2-1 ii libexif12 0.6.22-2 ii libgail-3-03.24.23-1 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-5 ii libglib2.0-0 2.66.0-1 ii libglib2.0-data2.66.0-1 ii libgtk-3-0 3.24.23-1 ii libnemo-extension1 4.6.5-1 ii libnotify4 0.7.9-1 ii libpango-1.0-0 1.46.1-1 ii libpangocairo-1.0-01.46.1-1 ii libselinux13.1-2 ii libx11-6 2:1.6.10-3 ii libxapp1 1.8.9-1 ii libxml22.9.10+dfsg-6 ii nemo-data 4.6.5-1 ii shared-mime-info 1.15-1 Versions of packages nemo recommends: ii cinnamon-l10n4.6.2-1 ii gvfs-backends1.44.1-1+b1 pn gvfs-fuse ii librsvg2-common 2.48.8+dfsg-1 ii nemo-fileroller 4.6.0-2 Versions of packages nemo suggests: pn eog ii evince [pdf-viewer] 3.36.7-1 ii mpg321 [mp3-decoder] 0.3.2-3.1 pn xdg-user-dirs -- no debconf information
