mntent-based implementation filter out mounts with device path that was
repeated. Consequently, it is not possible to show such mounts in UI even
with x-gvfs-show, because they are not returned from g_unix_mounts_get.
libmount-based implementation currently doesn't filter out any mounts
which causes issues to our volume monitors. Let's rather mark mounts
which don't point into fs root as system_internal. This approach won't be
affected by mount order as is mntent-based implementation. It will mark
more mounts as system_internal than it is filtered out with mntend-based
implementation, but there will be always possibility to show them in UI
over x-gvfs-show, which was not possible with mntend-based. We can
probably introduce some improvements later to not mark unique mounts as
system internal even if they don't point into fs root...
https://gitlab.gnome.org/GNOME/glib/issues/1271
Currently, there isn't API to determine root path for mounts created
over bind operation (or btrfs subvolumes). This causes issues to our
volume monitors if there is multiple mounts for one device, which can
happen with libmount-based implementation currently. Let's propagate
root path from libmount over g_unix_mount_get_root_path, so we can
handle this somehow in our volume monitors.
https://gitlab.gnome.org/GNOME/glib/issues/1271
These were callers which explicitly specified the string length to
g_utf8_validate(), when it couldn’t be negative, and hence should be
able to unconditionally benefit from the increased string handling
length.
At least one call site would have previously silently changed behaviour
if called with strings longer than G_MAXSSIZE in length.
Another call site was passing strlen(string) to g_utf8_validate(), which
seems pointless: just pass -1 instead, and let g_utf8_validate()
calculate the string length. Its behaviour on embedded nul bytes
wouldn’t change, as strlen() stops at the first one.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This introduces no real functional changes (except when compiling with
G_DISABLE_ASSERT, in which case it fixes the test). Mostly just a code
cleanup.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The code was checking whether the signature provided by the blob was a
valid D-Bus signature — but that’s a superset of a valid GVariant type
string, since a D-Bus signature is zero or more complete types. A
GVariant type string is exactly one complete type.
This meant that a D-Bus message with a header field containing a variant
with an empty type signature (for example) could cause a critical
warning in the code parsing it.
Fix that by checking whether the string is a valid type string too.
Unit test included.
oss-fuzz#9810
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Parsing a D-Bus message with the signature field in the message header
of type other than ‘g’ (GVariant type signature) would cause a critical
warning. Instead, we should return a runtime error.
Includes a test.
oss-fuzz#9825
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fedora is using https://fedoraproject.org/wiki/Changes/Annobin
to try to ensure that all objects are built with hardening flags.
Pass down `CFLAGS` to ensure the SystemTap objects use them.
When using glib as a meson subproject on Windows the build currently fails
due to too long paths during the build process. See
https://github.com/mesonbuild/meson/issues/4226 for the upstream bug.
To work around the issue shorten the filenames of the generated gdbus files.
The tests were making assumptions about the order of the returned D-Bus
introspection nodes. However, these are semantically unordered and
changes to e.g. GHashTable would break the tests.
Fix this by applying a sort prior to validation.
There are a lot of gbooleans in the private GTask struct, which seems a
bit wasteful. Use a bitfield to compress the struct a bit.
This reduces the size of the struct from 216 bytes to 168 bytes on my
64-bit machine.
One of the fields needs to remain separate, since it’s used from a
TRACE() macro which calls typeof() on it.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
These functions already check to see if a successful result has already
been returned; expand them to also check to see if an error has been
returned.
We can’t just check GTask.result_set, as that’s actually an indicator
for whether the GTask.result member is filled — when
g_task_propagate_*() is called, it’s cleared again. We need a new state
bit.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1525
This method drops the last reference *it* owns to the GTask, but then
continues to call methods on the GTask. This wasn’t resulting in
failures because a ref in another thread kept the GTask alive, but
that’s quite dodgy.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The X-Flatpak-RenamedFrom key is used in .desktop files to identify past
names for the desktop file. It is defined to be a list of strings.
However, there was previously no correct way to retrieve a list of
strings from the GKeyFile wrapped by GDesktopAppInfo, short of
re-parsing the file with GKeyFile.
Note that doing something like:
g_strsplit (g_desktop_app_info_get_string (...), ";", -1)
is not correct: the raw value "a\;b;" represents the one-element list
["a;b"], but g_key_file_get_string() rejects the sequence "\;", and so
g_desktop_app_info_get_string() returns NULL in this case. (Of course, a
.desktop file with a semicolon in its name is a pathological case.)
Add g_desktop_app_info_get_string_list(), a trivial wrapper around
g_key_file_get_string_list(), similar to g_desktop_app_info_get_string()
and co.
The change from g_key_file_free() to g_key_file_unref() in the test is
needed because g_key_file_free() clears the contents of the keyfile.
This is fine for all the fields which are eagerly loaded and copied into
GDesktopAppInfo, but not when we want to access arbitrary stuff from the
keyfile.
This avoids the convenience library being treated as though it was
an installed static library (objects not included in the dependent
static library, and convenience library being listed in the pkg-config
metadata), both of which would make static linking impossible.
This is a workaround for meson not having
https://github.com/mesonbuild/meson/pull/3939 merged yet.
Fixes: https://gitlab.gnome.org/GNOME/glib/issues/1536
Signed-off-by: Simon McVittie <smcv@collabora.com>
This makes it easier to debug test failures, by ensuring that g_debug()
and g_test_message() are printed as TAP diagnostics.
Fixes: https://gitlab.gnome.org/GNOME/glib/issues/1528
Signed-off-by: Simon McVittie <smcv@collabora.com>
None of these files starts with a #! line, and they are not native
binary executables, so if a user attempts to execute them as a program,
Unix shells will run them as /bin/sh scripts. This is not going to end
well, since none of them are shell scripts (the gio bash completion
is for bash, which is not a lowest-common-denominator POSIX shell, and
in any case is designed to be sourced rather than executed).
Fixes: #1539
Signed-off-by: Simon McVittie <smcv@collabora.com>
These keep on taking just longer than 30s on my local machine when run
in parallel with the rest of the tests (i.e. with `ninja test`). Testing
them individually, they do terminate correctly.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
g_icon_new_for_string() docs states that it should return a single name
when created with a single name. I add a second condition to this case:
the themed icon must not include default fallbacks (i.e. it must not
have been created with `g_themed_icon_new_with_default_fallbacks()`).
Otherwise the return value of `g_icon_new_for_string()` would not
recreate the same icon list when passed to `g_icon_new_for_string()`
(which would be another documentation inconsistency).
g_icon_new_for_string() is now back to old behavior for this specific
case.
I also revert the unit test for this case, and add a new unit test when
using g_themed_icon_new_with_default_fallbacks() with a single name as
well.
Closes#1513.
Currently this function calls `g_warning()` explicitly. It would be
nicer to properly propagate these failure up to the caller that tried to
initialise us.
`read_netlink_messages()` is the callback attached to the netlink socket
(G_IO_IN). It calls `g_socket_receive_message()`. There is a race
condition that if the socket is closed while there is a pending call, we
will try to receive on a closed socket, which fails.
To avoid this, we switch the order of the operations around: first
destroy the source and then close the socket.
This is not a correct way to check if `g_socket_new_from_fd()` failed.
Instead just see if it returned `NULL` itself.
This was preventing the netlink monitor from being initialised.
Closes#1518
All the other initialisation failure paths set a GError, but this one
didn’t. Set a GError to avoid breaking the invariant that returning
FALSE should always have a GError set.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1523
