When using `copy_file_range` to target a source and dest on the same NFS
mount on some older kernel versions, it's possible that we can get
`EOPNOTSUPP` e.g. if the NFS server doesn't support server-side copy.
We hit this in the FCOS release pipeline where we run `ostree
pull-local` to pull content between two repos on the same mount from
inside an OpenShift cluster on top of RHEL7.
Nowadays, it seems like the kernel itself falls back to a more generic
version of `copy_file_range()` at least. Though to be compatible with
older kernels, let's add `EOPNOTSUPP` to the list of errors we interpret
as "cfr possibly available, but can't be done for this specific
operation".
We don't modify this struct (if non-NULL), so it can be const. In
particular, this is helpful if calling glnx_file_copy_at() from
nftw() to implement the equivalent of `cp -a --reflink=auto`.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This doesn't really matter, since it only happens when our process is
about to exit anyway, but it makes it easier to use AddressSanitizer
and similar tools.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Otherwise, clang diagnoses it as unused. It is - deliberately - only
allocated and cleaned up, with no other use.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If you're building on a really old GLib, you might not have GTask,
GSubprocess or g_markup_parse_context_unref(), among others. This gets
libglnx compiling (and apparently working) on GLib versions as old
as 2.32.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This will be necessary if targeting GLib versions older than 2.34,
such as GLib 2.32 in Ubuntu 12.04 and the Steam Runtime.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is useful if you need the file to be on a particular filesystem.
In particular, flatpak wants this to make tempfiles on /tmp for things
we need to write during flatpak run, such as the libseccomp output fd.
We've had "flatpak run" stop working in low disk situations without this,
so its nice to be able to fix it.
This doesn't exist on some very old platforms. In the original file
in systemd, it was here for char32_t and char16_t, which we don't use.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The docs for `glnx_file_replace_contents[_with_perms]` say that the default mode
is 0666 - umask, but it's actually 0644. Because there's no thread-safe way of
finding out the current umask without grubbing around in /proc/self/status,
simply make the docs reflect reality.
This was inherited from some other code; perhaps the idea
was to ensure the console is in a consistent state before starting
a progress bar, but it causes extra newlines which is distracting.
In glibc 2.27, a wrapper for `copy_file_range` was added[1]. The
function is now always defined, either using a userspace fallback or
just returning `ENOSYS` if the kernel doesn't support it. This throws
off our preprocessor conditionals. Work around this by just renaming our
implementation differently. This is similar to what systemd did[2].
Hit this when trying to build on F28, which rebased to glibc 2.27.
[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=bad7a0c81f501fbbcc79af9eaa4b8254441c4a1f
[2] 5187dd2c40
glibc 2.27 added support for memfd_create. Unfortunately flatpak-builder,
or rather the included libglnx library, also has such a function to
wrap the corresponding syscall. It correctly tries to detect it in
the configure script to disabled the wrapper in case glibc provides
it. However it doesn't work due to a missing include.
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890722
Share its static var goodness with clients. This will be used in
rpm-ostree from various places which sometimes do use a `GLnxConsole`
and sometimes don't, so it's more convenient to make it its own
function.
