William Manley 6bf55255e8 listxattr: Don't assume that first call to listxattr gives correct size
To get the right sized buffer to pass to `flistattr` and `llistattr` we
first call them with a zero byte buffer.  They then return the number of
bytes they'll actually need to operate.  We would `malloc` and then call
again assuming that the size we got originally was correct.

On my computer at least this isn't always the case.  I've seen instances
where the first call returns 23B, but then on the second one returns no
data at all.  Getting these non-existant xattrs would then cause ostree
to fail.

I'm not sure why it's behaving this way on my machine.  I suspect its some
interaction with overlayfs but I haven't proven this.
2017-01-29 03:22:46 -05:00
2015-02-19 15:35:35 -05:00
2015-02-25 21:44:54 -05:00
2015-12-01 16:32:59 +01:00
2015-12-01 16:32:59 +01:00
2016-05-30 11:22:23 -04:00
2015-04-07 12:29:07 -04:00
2015-04-01 05:42:26 -04:00
2016-08-30 16:14:22 -04:00
2016-10-05 10:53:45 -04:00
2016-08-31 16:40:17 -04:00
2016-08-30 16:14:22 -04:00

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 a GCancellable to support dynamic cancellation
  • APIs also have a GError parameter
  • High level "shutil", somewhat inspired by Python's
  • A "console" API for tty output
  • 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.

Description
No description provided
Readme 66 MiB
Languages
C 91.1%
Shell 5.1%
Python 1.8%
Meson 1.1%
Yacc 0.8%