This effectively reverts commit 663ee11fda
for this `meson.build` file. This `meson.build` file isn’t actually
pulled into the main GLib (or GIO) build; it’s actually just installed
and then later called from a `meson` subprocess of `static-link.py`.
So it doesn’t have access to the `app_profile_dep` variable, which is
internal to GLib.
Fixes this CI failure: https://gitlab.gnome.org/GNOME/glib/-/jobs/5834610
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Since this list was originally created, more file system types have
become commonly used and would benefit from being marked as a system
file-system type.
This was found while tracking down some performance issues in
gnome-settings-daemon trash handling.
The code assumes that find_dbus_process_path() will return a wide
character string that is no longer than MAX_PATH. But this might not be
guaranteed to be true.
This was flagged in #YWH-PGM9867-119. The vulnerability hunter failed to
find any way to reach this code, so maybe it's not actually possible,
but we might as well check the size to be safe.
`SHFileOperationW()` may not always return success in case of
user-aborted operation, `ERROR_CANCELLED` was also observed
when cancelling a move-to-recycle-bin confirmation dialog.
Ensure `G_IO_ERROR_CANCELLED` is properly reported to the application,
instead of the generic `G_IO_ERROR_FAILED`.
`filename` should always be absolute when it's passed to `faccessat` so
this shouldn't change the behavior.
Apparently NetBSD checks the value of `dirfd` even when `pathname` is
absolute which results in an error:
https://gitlab.gnome.org/GNOME/glib/-/issues/3495#note_2605408
Many libc implementations seem to be incompatible with this
optimisation.
Printing an error when the error is either `EINVAL` or `EBADF` should
make it easier to identify any more problematic platforms.
match
This expands on the previous fixes to the kqueue backend testing, to
always treat `CHANGES_DONE_HINT` as optional when there is a mismatch
checking the expected events.
Also re-enable the tests for macOS.
Helps: #1392
Current code was clearly considering the case of having only a filename
as a directory monitoring, instead of a hard-link monitoring. As I
assume that hard links don't exist on Windows, this case should simply
revert back to the basic file monitoring code path.
This makes sure that extensions can generate code at the expected
places, and change the GDBusInterfaceSkeleton subtype that generated
skeletons derive from.
This allows us to create a copy of an argument without going through
GValue. The codegen here does not have any use for it, but we will add
an extension system in a later commit. The libdex codegen extension will
make use of it to define a boxed type for the method return values.
The out type can be different from the in types in their qualifiers and
thus are not always simply a reference to the in type. However, the out
types used to include the reference instead of the "base" type because
the code generator always used them in places where we actually needed a
reference to the out type (e.g. as out params).
For example, the codegen here generates:
gboolean dex_dbus_ping_pong_call_ping_sync (
DexDbusPingPong *proxy,
const gchar *arg_name,
gchar ** out_pong,
GCancellable *cancellable,
GError **error);
Where `gchar **` is the out type. If we want to codegen a function which
returns the out params in a struct, it would need to look like this:
typedef struct _DexDbusPingPongPingResult
{
gchar * pong;
} DexDbusPingPongPingResult;
Where neither the out type `gchar **` nor the in type `const gchar *` is
appropriate.
This changes the ctype_out to be the base type, and makes the codegen
add the reference explicitly.
A mount table is inherently trusted, so this isn't really a security
issue, but let's not write out of bounds. If anybody is still using GLib
on AIX, then you're welcome.
Discovery and patch credit: mhzcyber - Mohammad Hussam Alzeyyat
(I, Michael, only wrote this commit message and adjusted the
whitespace.)
This adds the condition that a new unix address is tried only when there
is enough space to append random character(s) before the address reach
the length of UNIX_PATH_MAX.
Before this change, creating a GDBusServer with unix addresses longer
than UNIX_PATH_MAX that existed in the filesystem would never return. A
test that expects G_IO_ERROR_ADDRESS_IN_USE in such scenario was added.
If asked to replace a file (i.e. effectively delete and re-create it)
which is a symlink, in a read-only directory, the code would end up
trying to do operations on an invalid `fd`. This was masked when asked
to create a backup, as creating the backup in the read-only
directory would error out just in time.
Make the code a bit more robust in this situation, and add some unit
tests.
Spotted by scan-build.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fallback for non-Linux systems that support the _SC_PHYS_PAGES and
_SC_AVPHYS_PAGES sysconf selectors, such as Solaris & OpenBSD.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Previously the len passed to g_socket_address_new_from_native() was only
for IPv4 addresses and the constructor would fail.
This was reported and discussed here:
fe0139ee98 (note_2581394)
add implementations for these functions using st_{a,c,m}timespec when
__APPLE__ is defined. Also re-enable the g-file-info test for darwin.
Fixes#3070, #2608
`GDBusProxy` implements this interface but allows construction with a
`NULL` interface info and also marks its getter/setter for the interface
info accordingly.
Callers of `g_dbus_interface_get_info()` need to assume that it can
return `NULL` unless they constructed the `GDBusInterface` in a way that
guarantees that the interface info is available.
The connectivity is directly derived from the `is_available` variable,
so if that changes, we need to notify of a change in `connectivity` too.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3803
When a snap is launched from its non-dbus-activable desktop file we may
still need to use the portal to pass the URIs to the program, so that it
can access to them even if confined.
In fact most snaps are not dbus-activable, but they rely on the classic
desktop file activation.
Snap applications like flatpak apps may need to use the portals to open
files, so use the same logic that we have for flatpaks but using the
snap ID that matches portal expectations
