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?

>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?

<linux/stat.h> 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