113c770dc1
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.
libglnx is the successor to libgsystem: https://git.gnome.org/browse/libgsystem
It is for modules which depend on both GLib and Linux, intended to be used as a git submodule.
Features:
- File APIs which use
openat()like APIs, but also take aGCancellableto support dynamic cancellation - APIs also have a
GErrorparameter - High level "shutil", somewhat inspired by Python's
- A "console" API for tty output
- Some basic container utility functions
- A backport of the GLib cleanup macros for projects which can't yet take a dependency on 2.40.
Why?
There are multiple projects which have a hard dependency on Linux and GLib, such as NetworkManager, ostree, xdg-app, etc. It makes sense for them to be able to share Linux-specific APIs.
This module also contains some code taken from systemd, which has very high quality LGPLv2+ shared library code, but most of the internal shared library is private, and not namespaced.
One could also compare this project to gnulib; the salient differences there are that at least some of this module is eventually destined for inclusion in GLib.
Porting from libgsystem
For all of the filesystem access code, libglnx exposes only
fd-relative API, not GFile*. It does use GCancellable where
applicable.
For local allocation macros, you should start using the g_auto
macros from GLib. A backport is included in libglnx. There are a few
APIs not defined in GLib yet, such as glnx_fd_close.
gs_transfer_out_value is replaced by g_steal_pointer.
Contributing
Currently there is not a Bugzilla product - one may be created in the future. You can submit PRs against the Github mirror:
https://github.com/GNOME/libglnx/pulls
Or alternatively, email one of the maintainers directly.