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>
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.
