Package: libglib2.0-0 Version: 2.58.3-2+deb10u2 Severity: important g_file_copy_attributes(), when invoked with G_FILE_COPY_ALL_METADATA on files in NFS, is prone to truncating the value of extended attribute system.nfs4_acl. Here is an excerpt from strace output, showing the getxattr() and setxattr() calls:
getxattr("/home/xxx/a", "system.nfs4_acl", 0x7ffef8b54a20, 63) = -1 ERANGE (Numerical result out of range) getxattr("/home/xxx/a", "system.nfs4_acl", NULL, 0) = 80 getxattr("/home/xxx/a", "system.nfs4_acl", "\0\0\0\3\0\0\0\0\0\0\0\0\0\26\1\247\0\0\0\6OWNER@\0\0\0\0\0", 80) = 80 setxattr("/home/xxx/b", "system.nfs4_acl", "", 0, 0) = -1 EIO (Input/output error) Note how the attribute value was truncated from 80 bytes to 0. I believe this is because the value starts with a 0 byte. gio/glocalfileinfo.c:escape_xattr() does not make use of the len argument when computing escaped_val, but instead invokes strlen() which is unsuitable for binary strings. A look at the latest upstream version, 2.64.3, suggests the problem is still there. This impacts such operations as "Save As" in evince. Due to an unrelated bug I recommend running a recent kernel (e.g., 5.5 rather than 4.19) when attempting to reproduce this problem.