Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1024896 > unrolled thread

Bug#970228: nemo: Can no longer copy files

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#970228: nemo: Can no longer copy files Holger Schröder <Holgi.HSP@gmx.de> - 2020-09-13 11:40 +0200
    Bug#970228: nemo: Can no longer copy files Holger Schröder <Holgi.HSP@gmx.de> - 2020-09-13 22:40 +0200
      Bug#970228: nemo: Can no longer copy files Norbert Preining <norbert@preining.info> - 2020-09-14 00:40 +0200
        Bug#970228: nemo: Can no longer copy files Simon McVittie <smcv@debian.org> - 2020-09-14 10:20 +0200
          Bug#970228: nemo: Can no longer copy files Holger Schröder <Holgi.HSP@gmx.de> - 2020-09-14 11:30 +0200
            Bug#970228: nemo: Can no longer copy files Simon McVittie <smcv@debian.org> - 2020-09-14 11:40 +0200
              Bug#970228: nemo: Can no longer copy files Holger Schröder <Holgi.HSP@gmx.de> - 2020-09-14 12:30 +0200
                Bug#970228: nemo: Can no longer copy files J Rowan <jrowan@jretrading.com> - 2020-09-14 22:10 +0200
              Bug#970228: nemo: Can no longer copy files Holger Schröder <Holgi.HSP@gmx.de> - 2020-09-14 21:30 +0200
                Bug#970228: nemo: Can no longer copy files Joe <joe@jretrading.com> - 2020-09-14 22:10 +0200
          Bug#970228: nemo: Can no longer copy files Simon McVittie <smcv@debian.org> - 2020-09-14 21:50 +0200
          Bug#970228: nemo: Can no longer copy files Simon McVittie <smcv@debian.org> - 2020-09-14 23:10 +0200
            Bug#970228: nemo: Can no longer copy files Holger Schröder <Holgi.HSP@gmx.de> - 2020-09-15 09:50 +0200
              Bug#970228: nemo: Can no longer copy files Simon McVittie <smcv@debian.org> - 2020-09-15 10:10 +0200
                Bug#970228: libglib2.0-0: 2.66.x cannot copy files on some filesystems (ZFS with noatime, CIFS/SMB) Simon McVittie <smcv@debian.org> - 2020-09-15 12:50 +0200
    Bug#970228: nemo: Can no longer copy files Joe <joe@jretrading.com> - 2020-09-15 10:50 +0200

#1024896 — 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-0                2.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-0                3.24.23-1
ii  libgdk-pixbuf2.0-0         2.40.0+dfsg-5
ii  libglib2.0-0               2.66.0-1
ii  libglib2.0-data            2.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-0        1.46.1-1
ii  libselinux1                3.1-2
ii  libx11-6                   2:1.6.10-3
ii  libxapp1                   1.8.9-1
ii  libxml2                    2.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-l10n    4.6.2-1
ii  gvfs-backends    1.44.1-1+b1
pn  gvfs-fuse        <none>
ii  librsvg2-common  2.48.8+dfsg-1
ii  nemo-fileroller  4.6.0-2

Versions of packages nemo suggests:
pn  eog                   <none>
ii  evince [pdf-viewer]   3.36.7-1
ii  mpg321 [mp3-decoder]  0.3.2-3.1
pn  xdg-user-dirs         <none>

-- no debconf information

[toc] | [next] | [standalone]

#1024947

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.


...

[toc] | [prev] | [next] | [standalone]

#1024961

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

[toc] | [prev] | [next] | [standalone]

#1024994

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

[toc] | [prev] | [next] | [standalone]

#1024998

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.


...

[toc] | [prev] | [next] | [standalone]

#1025001

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

[toc] | [prev] | [next] | [standalone]

#1025006

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


...

[toc] | [prev] | [next] | [standalone]

#1025092

On Mon, 14 Sep 2020 12:16:05 +0200 =?UTF-8?Q?Holger_Schr=c3=b6der?=
<Holgi.HSP@gmx.de> 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

[toc] | [prev] | [next] | [standalone]

#1025080

I have tested Thunar from XFCE, same problem.


...

[toc] | [prev] | [next] | [standalone]

#1025089

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

[toc] | [prev] | [next] | [standalone]

#1025084

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

[toc] | [prev] | [next] | [standalone]

#1025096

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

[toc] | [prev] | [next] | [standalone]

#1025144

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

[toc] | [prev] | [next] | [standalone]

#1025148

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

[toc] | [prev] | [next] | [standalone]

#1025176 — Bug#970228: libglib2.0-0: 2.66.x cannot copy files on some filesystems (ZFS with noatime, CIFS/SMB)

Control: reassign -1 libglib2.0-0 2.66.0-1
Control: retitle -1 libglib2.0-0: 2.66.x cannot copy files on some filesystems (ZFS with noatime, CIFS/SMB)
Control: forcemerge -1 970263
Control: affects -1 + nemo thunar nautilus libglib2.0-bin
Control: forwarded -1 https://gitlab.gnome.org/GNOME/glib/-/issues/2205
Control: severity -1 important
Control: tags -1 = upstream patch

On Tue, 15 Sep 2020 at 09:08:46 +0100, Simon McVittie wrote:
> 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.

I've sent this upstream as
<https://gitlab.gnome.org/GNOME/glib/-/issues/2205>.

The change proposed in
<https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1648> seems to
address the problem for at least ZFS. I'll try to get that uploaded to
Debian soon, but doing a full build and QA checks for GLib can take hours,
so please be patient.

If you're able to build a patched package locally, please see whether
the changes from the upstream MR help.

On Mon, 14 Sep 2020 at 20:26:21 +0100, J Rowan wrote:
> 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. 

Because the bug was cloned and only the clone was reassigned to
libglib2.0-0, only the maintainers of nemo got your messages, and the
maintainers of libglib2.0-0 (e.g. me) didn't see them. I'm moving the
original bug from nemo to libglib2.0-0 so that all subsequent messages
get to the right people.

How, precisely, you accessing those Samba shares? There are several
ways you might be accessing them.

Based on my analysis of the equivalent issue with ZFS, if it is really
the same bug affecting you, then I suspect you have mounted them
as filesystems in the local VFS (mount -t cifs or mount -t smbfs,
or an equivalent line in fstab). If that's the case, please tell me
the exact mount command or line in fstab that you are using, so that
I can reproduce something similar. You can censor names of machines,
shares etc. if you want to, as long as it's obvious what you've done;
for example if the command you really used was
"mount -t cifs -o rw,noatime //server1/corporate_secrets /mnt/corp_secrets",
it's OK to quote that as
"mount -t cifs -o rw,noatime //MACHINE/SHARE /mnt/MOUNT".

I'd also like to see the the line describing the Samba mount point
in /proc/self/mountinfo; again, you can censor it in obvious ways if
necessary.

If you are using some other way to access Samba shares (for example typing
smb:// URLs into Nautilus or navigating to a path in /run/user/1000/gvfs),
and you see this bug that way, then please describe that with a similar
level of detail.

If you're using local VFS mount points as I suspect, then you might
be able to work around this bug by using the smb:// URL of the share,
instead of its local mount point, to access it in your graphical
file manager. For example, in Nautilus you could press Ctrl+L, type
smb://server1/corporate_secrets, press Enter, and then copy files using
the resulting window. That's likely to bypass the part of GLib affected
by this bug.

    smcv

[toc] | [prev] | [next] | [standalone]

#1025163

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web