To fill in some gaps, I've had to make some assumptions:
* trivial changes (such as checking for an additional function or
header file in libglnx.m4) are assumed to not be copyrightable
* Will Thompson and Matthew Leeds are assumed to be contributing on
behalf of Endless Mobile Inc.
* files with no explicit licensing information are assumed to be
under the license found in COPYING
Reference: https://reuse.software/
Signed-off-by: Simon McVittie <smcv@debian.org>
This avoids colliding with a config.h generated by a parent Meson
project.
In the Meson build system, we generate libglnx-config.h by doing our
own checks, so we want to avoid it colliding.
In the Autotools build system, we assume that the parent project will
generate its own config.h that contains the results of LIBGLNX_CONFIGURE,
and create a forwarding header libglnx-config.h in the $(top_builddir)
(so that it is next to config.h).
Note that after updating libglnx in an Autotools non-recursive-Make
project (libostree, flatpak, flatpak-builder) it will be necessary to
re-run autogen.sh.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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
Planning to use memfd_create() in flatpak and rpm-ostree, which both use
bubblewrap, and want to pass read-only data via file descriptor to the
container. Passing via `O_TMPFILE` requires `O_RDWR` (read and write),
and passing via a pipe would require buffering.
The systemd `missing.h` has grown enormously; I only cherry-picked the bits for
memfd.
FICLONE is the new alias for the formerly btrfs-specific ioctl; XFS
has experimental patches to support it.
Further, we should use copy_file_range() for the case where we're only doing a
limited copy. Both NFS and XFS (with reflink enabled) understand it.
Part of the reason I'm doing this is so that ostree's `/etc` merge will start
using XFS reflinks. But another major reason is to take the next step after and
copy this code into GLib as well, so that all of the general GLib users will
benefit; e.g. Nautilus will transparently do server copy offloads with NFS home
directories.
See also this coreutils thread about `copy_file_range()`:
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24399>. I don't care about file
holes for our use cases, so it's fine.
Other changes while I'm here:
- Tweak the sendfile() case to match the newly inlined logic for cfr
- Add a TEMP_FAILURE_RETRY() around the read()
We had a bug previously where we failed to clean up a temporary file
in an error path. This is a classic case where the new `O_TMPFILE`
API in Linux is nicer.
To implement this, as usual we start with some original bits from
systemd. But in this case I ended up having to heavily modify it
because systemd doesn't support "link into place and overwrite". They
don't actually use their tempfile code much at all in fact - as far as
I can tell, just in the coredump code.
Whereas in many apps, ostree included, a very common use case is
atomically updating an existing file, which is
`glnx_file_replace_contents_at()`, including subtleties like doing an
`fdatasync()` if the file already existed.
Implementing this then is slightly weird since we need to link() the
file into place, then rename() after.
It's still better though because if we e.g. hit `ENOSPC` halfway
through, we'll clean up the file automatically.
We still do keep the mode where we error out if the file exists.
Finally, the ostree core though does have a more unusual case where we
want to ignore EEXIST (allow concurrent object writers), so add
support for that now.
Note: One really confusing bug I had here was that `O_TMPFILE` ignores
the provided mode, and this caused ostree to write refs that weren't
world readable.
Rework things so we always call `fchmod()`, but as a consequence we're
no longer honoring umask in the default case. I doubt anyone will
care, and if they do we should probably fix ostree to consistently use
a mode inherited from the repo or something.
