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
Reply to: