[bug] glnx_regfile_copy_bytes fails on ecryptfs due to copy_file_range
Context
- Debian 11
-
uname -a
: Linux kinn 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64 GNU/Linux - $HOME is on
ecryptfs
(with ext4 as backing device) - libglnx version: ef502aab
Issue
While debugging an issue with flatpak and ostree, I discovered that my system doesn't like the usage of copy_file_range
in $HOME. It reports EINVAL
on my system even without proper parameters and then simply exits returns without any fall-back.
Disabling cfr
makes the function work:
diff --git a/glnx-fdio.c b/glnx-fdio.c
index 3fa73b5..bca6694 100644
--- a/glnx-fdio.c
+++ b/glnx-fdio.c
@@ -782,7 +782,7 @@ int
glnx_regfile_copy_bytes (int fdf, int fdt, off_t max_bytes)
{
/* Last updates from systemd as of commit 6bda23dd6aaba50cf8e3e6024248cf736cc443ca */
- static int have_cfr = -1; /* -1 means unknown */
+ static int have_cfr = 0; /* -1 means unknown */
bool try_cfr = have_cfr != 0;
static int have_sendfile = -1; /* -1 means unknown */
bool try_sendfile = have_sendfile != 0;
EDIT: While stepping through the source I found that sendfile
is not used either. It also reports EINVAL
, but in contrast to copy_file_range
EINVAL
disables the usage of sendfile
.
The boost people had a similar bug report a while ago: https://github.com/boostorg/filesystem/issues/184
lucab pointed me to a similar issue in systemd: https://github.com/systemd/systemd/pull/18810
For reference, this is issue in the ostree repo: https://github.com/ostreedev/ostree/issues/2525#issuecomment-1020121886