- Jul 31, 2017
-
-
Colin Walters authored
We should be able to rely upstream on everything *except* `glnx_unref_object` which requires the library itself to depend on a newer glib, which isn't true for e.g. RHEL7 libsoup. libostree was almost ready for this; just a few patches to push it to completion in https://github.com/ostreedev/ostree/pull/1042
-
- Jun 14, 2017
-
-
Colin Walters authored
I originally tried to get this into GLib: https://bugzilla.gnome.org/show_bug.cgi?id=783751 But that looks like it's going to fail due to MSVC. Let's add it here at least so I can start using it tomorrow and not wait for the MSVC team to catch up. I renamed `glnx-alloca.h` to `glnx-macros.h` as a more natural collective home for things from systemd's `macro.h`. Finally, I used a Coccinelle spatch similar to the one referenced in the above BZ to patch our uses.
-
- May 30, 2017
-
-
Colin Walters authored
Not everything, but a good chunk of the remaining bits.
-
- Jan 29, 2017
-
-
Colin Walters authored
This is symmetric with an earlier commit which handled a transition from `size != 0` -> `size = 0`. Now if xattrs are added we retry.
-
Colin Walters authored
By taking both fd and path into one copy of the reader func, exactly like we do in `read_xattr_name_array`, we can abstract over the difference. Preparatory cleanup for more work here.
-
Colin Walters authored
We should be robust in the face of this and return a snapshot of the current value we saw, not transiently fail. This is the semantics we expect with ostree upgrades for `/etc` for example.
-
William Manley authored
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.
-
- Feb 20, 2015
-
-
Colin Walters authored
This also uses GBytes and avoids malloc where possible.
-
- Feb 15, 2015
-
-
Colin Walters authored
-
Colin Walters authored
-