If we don't do this, users of libglnx all have to add this dependency
themselves, otherwise they'll get errors like:
fatal error: gio/gfiledescriptorbased.h: No such file or directory
Signed-off-by: Simon McVittie <smcv@collabora.com>
It seems that on SELinux systems, files in /proc have extended
attributes that cannot be copied by an unprivileged user.
Signed-off-by: Simon McVittie <smcv@debian.org>
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>
Some pseudo-files in /proc and /sys list a size of 0 bytes in stat()
results, but do in fact have content. For these pseudo-files, the only
way to find out the true file size is to try read() until EOF, so leave
the max_bytes set to -1.
copy_file_range() and sendfile() don't work for such files in some
kernel versions (see <https://lwn.net/Articles/846403/>), so skip the
fast-paths and use a read() and write() loop. For pseudo-files, we
expect to be able to copy the whole content in one read() in any case.
Signed-off-by: Simon McVittie <smcv@debian.org>
Although EINVAL usually indicates a programming error, ecryptfs (and
possibly other stacked filesystems) returns EINVAL for attempts to
copy_file_range() or sendfile() between files on that filesystem.
Resolves: https://gitlab.gnome.org/GNOME/libglnx/-/issues/3
When we free `xattr_name`, we need to transfer ownership away to avoid
potential for a double-free if we hit `ENOTSUP` on the next iteration.
Reported-by: Seth Arnold <seth.arnold@canonical.com>
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>
It's not smart enough to follow the conditionals here to see
that `textlen > 0` implies `text != NULL`. But the cost of an additional
check is probably nil, so let's be robust to future code refactoring.
This is useful in the same situations rewinddir() is. My use-case right
now is to remove some of the files from a directory, then go back through
the directory removing symlinks that pointed to those files.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In some contexts, we may want to copy a root-owned file but we're not
running as root so we can't `fchown` it. (The case I'm interested in is
actually a bit more obscure than this: running in a supermin VM as root,
and wanting to copy a file we created onto a 9p mount where we don't
have perms to `fchown`).
Add a `GLNX_FILE_COPY_NOCHOWN` to handle this case.
This make replaced files have a strictly increasing st_mtime. The main
usecase I have for this is to ensure the summary file mtime increases
because the flatpak tests are failing due to the python httpd used
in the tests rely on st_mtime for the http If-Modified-Since header.
For the tests this breaks all the time since we're just doing a lot of
summary updates. However, I can see this accidentally happening in the
wild too, so i think its proper to always ensure the new summary is
"newer", even though it means it will be timestamped slightly in the
future. In practice this will not happen regularly, and the times it
*does* happen we really do need it.
`glnx_open_anonymous_tmpfile` attempts to create an fd in `/var/tmp`
regardless of the value of `$TMPDIR`.
This is _usually_ okay, but can fail in some contexts, such as in the
[NixOS][1] build environment, which doesn't have `/var` mapped at all.
To avoid failing in this case, if the inner call to
`glnx_open_anonymous_tmpfile_full` fails, we retrieve the value of
`$TMPDIR` and try calling `glnx_open_anonymous_tmpfile_full` again with
that directory instead.
In the fast path (i.e. where `/var/tmp` exists), functionality is
unchanged.
[1]: https://nixos.org/
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>
