The functionality that was prototyped in libglnx as glnx_fd_close
and then glnx_autofd was later added to GLib as g_autofd.
glnx_close_fd() doesn't have a direct equivalent in GLib, so keep
it intact, but using the backported _glnx_clear_fd_ignore_error as
its implementation. g_clear_fd() is the closest thing in GLib, but
g_clear_fd() guarantees to set errno on failure (making it useful for
error-checking), whereas glnx_close_fd() guarantees to leave errno
untouched, making it more useful for cleanup code paths that recover
from a syscall or similar function that sets errno:
int fd = ...;
success = (fsync (fd) == 0);
glnx_close_fd (&fd);
return success; /* if false, errno indicates why fsync failed */
(Of course in many cases, including this simple example, it would have
been easier to use g_autofd.)
glnx_autofd and glnx_fd_close are now equivalent to the backport of
g_autofd, so document them as deprecated. There's essentially no cost to
retaining them, so don't apply deprecation attributes.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This overflows, which is undefined behaviour (in practice it will usually
wrap around into unsigned space, but this can't be guaranteed).
Signed-off-by: Simon McVittie <smcv@collabora.com>
The selling features are:
* Support for RESOLVE_BENEATH, RESOLVE_IN_ROOT and RESOLVE_NO_SYMLINKS
* Fallback from openat2 to open_tree to openat for compatibility
* Triggering of automounts
test_data is an array of (usually) signed char, but
glnx_file_replace_contents_at() takes an array of unsigned bytes.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Formally, `strlen("x")` is not a constant expression, although gcc can
and does optimize it to a constant expression in simple cases.
clang 19.1.6 warns about this usage.
Replace it with the size of a static array (1 more than the strlen of
its contents), which is unambiguously a constant expression.
Resolves: https://gitlab.gnome.org/GNOME/libglnx/-/issues/5
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is a slight generalization of the reproducer contributed by Will
Thompson: as well as exercising the case where the parent is a dangling
symlink (reproducing GNOME/libglnx#1), this also exercises the case where
the parent is a non-directory non-symlink (in this case a regular file).
Reproduces: GNOME/libglnx#1
Co-authored-by: Will Thompson <wjt@endlessos.org>
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we try to create `link/content` where `link` is a dangling symlink,
recursing to create `link` will succeed (mkdirat fails with EEXIST,
which is explicitly ignored), but then mkdirat for `link/content` will
still fail. Fail gracefully instead of crashing out with an assertion
failure.
Resolves: GNOME/libglnx#1
Signed-off-by: Simon McVittie <smcv@collabora.com>
Otherwise it could potentially race with tests in other executables that
also want to create `./test`, or interfere with other test-cases in the
same executable that expect `./test` to be nonexistent or empty.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Meson 1.1.0 officially deprecates string defaults for boolean options,
but boolean defaults worked in many older Meson versions, going back to
at least 0.49.x.
Signed-off-by: Simon McVittie <smcv@collabora.com>
When compiling with GLib older than 2.80.x, we provide a compatibility
backport of g_closefrom() and g_fdwalk_set_cloexec(), but when compiling
with newer GLib, we rely on GLib to provide those.
The intended scope of libglnx (Linux only) is narrower than the scope
of `<glib-unix.h>` (any Unix platform), so we can safely include
`<glib-unix.h>` unconditionally. This provides least-astonishment by
having `#include <libglnx.h>` with newer GLib always provide a superset
of the functionality it provides with older GLib.
This would have avoided needing
https://github.com/flatpak/flatpak/pull/5737.
Fixes: 6ada39c3 "backports: Add a backport of g_closefrom(), g_fdwalk_set_cloexec()"
Signed-off-by: Simon McVittie <smcv@collabora.com>
Recent versions of openSUSE default to using -Werror=return-type for
package builds, which results in all of these function checks
incorrectly detecting the function as not being available.
Co-authored-by: Peng Yi
Resolves: https://gitlab.gnome.org/GNOME/libglnx/-/issues/4
Signed-off-by: Simon McVittie <smcv@debian.org>
These will be new API in GLib 2.79.2.
The only code change in the implementation, other than the _glnx
wrappers, was to use `close()` instead of `g_close (fd, NULL)` in a
context where it must be async-signal safe.
The test-case needed some more adjustments to be backwards-compatible
with GLib from the distant past.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We weren't passing the right path argument here.
This bug would've been quickly noticed if the function were actually
used but I still did at least a global GitHub search which didn't return
any users.
