g_win32_fs_monitor_handle_event() converts the new name of a rename
to UTF-8 and passes it to g_file_monitor_source_handle_event(), which
takes it as const and copies what it keeps. Nothing freed it, so every
reported rename leaked the string.
Rather than looking up the file system type with a 100-element `switch`
block, use `bsearch()`. At higher optimisation levels, modern GCC can
unwrap libc’s `bsearch()` and inline the comparison function, reducing
about 400 comparison/jump instructions to less than 30 implementing the
binary search.
See https://godbolt.org/z/cn88aado5
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Currently `g_desktop_app_info_ensure_saved()` assumes that if the object
does not have a filename, it was created with
`g_app_info_create_from_commandline()`, and therefore assumes
`info->exec`, `info->name` and `info->comment` are not NULL.
However, app info could have been also created with
`g_desktop_app_info_new_from_keyfile()`, which does not guarantee any of
those values. This results in failed assertions and broken resulting
filename, if these keys are not set in the key file.
The Name key is required by the Desktop Entry Specification, so make
`g_desktop_app_info_new_from_keyfile()` error out when the name is
missing, and check the remaining values in
`g_desktop_app_info_ensure_saved()`.
g_action_group_query_action() sets parameter_type to NULL for actions
without a parameter, state_type and state to NULL for stateless
actions, and state_hint to NULL when there is no hint. The matching
g_action_group_get_action_*() getters already mark these results as
nullable.
A successful g_file_enumerator_iterate() call returns NULL outputs at
exhaustion. Optional output locations and borrowed result lifetimes
remain unchanged.
Currently `g_desktop_app_info_set_as_default_for_type()` and
`g_desktop_app_info_set_as_last_used_for_type()` check if application's
ID is NULL, and error out accordingly.
This is because back when this mechanism was introduced in
229234111c,
app infos created with `g_desktop_app_info_new_from_filename()` would not
have application's ID set. However, since
c0af442909
and then
f065497acf
the application's ID is expected not to be empty. Moreover,
`g_desktop_app_info_ensure_saved()` guarantees it's set if it returns
true, so the error can never be returned.
Drop the unused check and error in those cases.
- Factor the core spawning logic into an internal helper.
- Add g_desktop_app_info_launch_uris_with_spawn_async() and _finish()
to handle their own GTask lifecycle, cancellation, and D-Bus flushing.
- Retain g_desktop_app_info_launch_uris_with_spawn() as a synchronous wrapper
for existing sync callers.
- Update launch_uris_bus_get_cb() to delegate to the async variant instead of
calling the synchronous spawn function.
Instead of calling g_dbus_connection_flush() in callers such as
g_desktop_app_info_launch_uris_internal() and
g_desktop_app_info_launch_action(), move the flush into
g_desktop_app_info_launch_uris_with_spawn().
This makes g_desktop_app_info_launch_uris_with_spawn() self-contained
in flushing the startup notification D-Bus messages it emits.
The flush was originally added in commit d6954c78 specifically to ensure
that fire-and-forget D-Bus signals emitted for startup notification
(notify_desktop_launch()) were not dropped if the session bus connection
was unreffed immediately afterwards.
Because notify_desktop_launch() is only called in the spawn path, the
other callers do not emit startup notification signals. The D-Bus
activation paths (g_desktop_app_info_launch_uris_with_dbus() and
g_desktop_app_info_launch_action()) use method calls whose lifecycle is
managed by GTask (which holds a reference to the connection until
complete), so they do not require an explicit flush.
`g_variant_builder_end()` returns a new floating reference. We don’t
want to pass a floating reference into the `before_emit()` and
`after_emit()` vfuncs, in case they sink it, so let’s sink it first and
then unref later to avoid the leak.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #4072
copy_file_range_with_progress() asked for the whole remaining length in
each copy_file_range() call, and only reported progress and checked the
cancellable between calls. Linux returns after at most 2GB, but FreeBSD
copies the full length in one call when the source and destination are
on different file systems. A large copy there reported no progress until
it had finished, and cancelling it took effect only once the whole file
had been copied.
Copy at most 8MiB per call. That gives about one progress update a
second on a slow USB stick; on fast storage the extra system calls are
negligible.
Closes#4069
Add a new flag to GMountMountFlags that allows callers to request
a read-only mount. This is needed by file managers (e.g. Thunar)
to allow users to mount removable drives as read-only.
The flag is passed through the GVolumeIface::mount_fn vfunc and
can be handled by volume monitor implementations (e.g. gvfs
udisks2) to pass the appropriate options to the underlying
mount mechanism.
Also add a --read-only / -r option to the gio mount CLI tool.
G_STRUCT_OFFSET (struct sockaddr_un, sun_path) == sizeof (struct sockaddr)
should hold, and therefor the compiler should optimize it away, but it's
not required. So be clear and add it.
If g_socket_address_new_from_native (addr, sizeof (sockaddr_un)) gets
called, the size of the path will be UNIX_PATH_MAX even if it is
a null-terminated string.
Ensure that we return UNIX_PATH_MAX - 1 (because we force null
ternmination) as the path length in this case.
When passing a filename of length UNIX_PATH_MAX via sockaddr_un it will
not be null-terminated. This will cause g_unix_socket_address_new() to
fail as it expects a null-terminated string.
Use g_unix_socket_address_new_with_type() instead as it allows passing a
length.
Testcase included.
Allow addresses of type G_UNIX_SOCKET_ADDRESS_PATH to be UNIX_PATH_MAX
characters long.
Previously they could only be UNIX_PATH_MAX - 1 characters long which
lead to an inconsistency with the UNIX APIs.
There is no implementation reason for this but correctness, where I
feared that AI exploit finders might find an exploit for this and wanted
to get ahead.
Testcase adapted for this usecase.
g_iconv_open() returns (GIConv) -1 on failure, but finalization
treated that sentinel as a valid descriptor. This can crash native iconv
implementations which do not tolerate it, including Solaris.
Preserve NULL as the not-initialized state, skip both invalid descriptor
values during finalization, and add coverage for unsupported charsets and
initialization which fails before opening a converter.
inotify watches are keyed by inode, so watching a directory (or file)
through two different paths that resolve to the same inode - e.g. a real
path and a symlink alias - returns the same watch descriptor (wd). The
backend already tracks this by keeping a GList of watched dirs/files per
wd.
However, when a monitor was cancelled, _ip_stop_watching() (and likewise
ip_watched_file_stop()) called _ik_ignore() -> inotify_rm_watch() as soon
as that particular path had no subscribers, without checking whether any
other path still shared the same wd. This tore down the single kernel
watch out from under the still-active monitors on the other path: they
kept reporting g_file_monitor_is_cancelled() == FALSE but silently
stopped receiving events.
Only remove the kernel watch once no other watched directory/file still
references the wd, by removing our own entry from the wd hash first and
issuing _ik_ignore() only when the list has become empty.
Add a regression test covering cancellation of a directory monitor
established through a symlink alias.
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/4055
Resources are generally considered trusted data (after all,
they are typically part of the same binary). But we should
still be robust and avoid underflow if we can. When the data
is not compressed, we subtract 1 from the length of the data
to omit a trailing \0, without checking first if the length
of the data was zero. Don't do that to avoid underflow.
Tests included. The tests were produced and validated with
the help of AI.
Related: RHEL-215289
When we expect that splitting a string should result in N tokens, we
don't need to split into more than N+1 tokens before we know it's an
error.
This is a hardening suggestion from an AI tool.
In some test cases (but not only) GLib needs to preload libraries when
launching executables, however this doesn't work well with ASAN because
libasan needs to be the first library to be loaded in such case.
We've been ignoring the error so far, using verify_asan_link_order=false
ASAN option, but this is not the correct way because it implies that
we don't check any pre-loaded library, as we instead should.
So in the platforms we know, get the proper sanitizer libraries paths
and pre-load them when required.
We don't do it for installed tests since the full paths may change in
the target system, so ignoring the error is safer.
This meson code has been used for various years now in fprintd project
to run tests in CI in both fedora and debian-based systems with no
issues, so I consider it reliable.
In case no preload variables are found the default ignore mode is used
If preloading a library is required asan doesn't work properly because
it requires to be the first loaded library to test everything, however
the behavior can be worked around using an ASAN_OPTIONS variable, so do
this to prevent the tests to fail completely
But instead of having to do it at test level, manage this at wider scope
The directories used for desktop application persistence are derived from
the user environment. In a setuid process, an unprivileged user can redirect
those writes through an intermediate symlink.
GIO is not designed for privileged use, so fail closed before resolving or
creating any user application or MIME configuration directory.
Closes#4003
Signed-off-by: Samy <samy@ap4.sh>
