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