Due to an oversight (I guess), per-desktop default values (which come
from override files such as this one:
https://github.com/endlessm/gnome-shell/blob/master/data/00_org.gnome.shell.gschema.override)
were not checked when getting a GSettings value via a `GSettingsAction`.
Per-desktop default values are correctly returned via all other
GSettings query paths (see calls to
`g_settings_schema_key_get_translated_default()`).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
We cannot use `gvisibility_h` for different visibility header files; you
never know when you're going to refer to the variable again, and
projects might end up needing to retrieve the variable contents—like,
for instance, gobject-introspection using glib as a subproject.
Fix a regression that appeared after adding support for nanosecond
timestamps to set_mtime_atime(). User-visible effect: when copying a
file from a gvfs MTP mountpoint to the local filesystem, the file's
mtime is set to 0.
This behavior happens when setting G_FILE_ATTRIBUTE_TIME_MODIFIED first,
then G_FILE_ATTRIBUTE_TIME_MODIFIED_USEC. Setting the second attribute
ends up in set_mtime_atime() with mtime_usec_value set, and mtime_value
== NULL. When mtime_value is NULL, the tv_sec part of the timestamp
should be fetched by lazy_stat(), but set_mtime_atime() fails to assign
it properly, and tv_sec stays at 0, leading to losing the main part of
the timestamp.
Fix the issue by setting times_n[1].tv_sec to the value fetched from
lazy_stat().
Fixes: b33ef610de ("Add functionality to preserve nanosecond timestamps")
Fixes: 15cb123c82 ("glocalfileinfo: don't call both utimes and utimensat")
Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com>
`search_token` cannot be `NULL` at this point (guaranteed by all the
current call sites of `desktop_file_dir_unindexed_search()`), so remove
an unnecessary `NULL` check.
Add an assertion to make the nullability clear.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1502196, #1502193
If the port is not specified, then a default port should be assumed.
This is how everybody expects URIs to work and it's how GProxyResolver
should work too.
We already have lots of tests to ensure this works as expected; however,
the documentation currently does not allow it. Change the documentation
to match reality.
Fixes#2832
When launching a registered handler we compose the command-line
string using the registered command-line template. Applications
expect files in their command-line as local paths rather than
complete URI strings.
For example,
"Program.exe" "%1"
Should expand to
"Program.exe" "C:\file.dat"
Rather than
"Program.exe" "file:///C:\file.dat"
Fixes https://gitlab.gnome.org/GNOME/glib/-/issues/2843
Substring matches can have too much unwanted results, while prefix
matches is more accurate but cannot handle some special cases, this
commit combines them by adding a match_type member, then sort and group
result with both categories and match types.
For the same category, prefix matched results will be put in the first
group and substring matched results will be put in the second group.
We eventually need to return them as an array anyways.
Sadly we can't just reuse such memory because each element is a pointer and
not a guchar, but still we can be cheaper in various operations.
I noticed this when running the test on an Arm Morello system where varargs
have bounds. g_variant_new() was trying to read an integer using va_arg(),
but since there was no argument it resulted in a bounds errors there.
On most other architectures this will just read whatever value is contained
in the next argument register and is not something that ASan can detect, so
it never resulted in test failures.
When a cancellable is cancelled when we call g_cancellable_connect we
used to immediately call the provided callback, while this is fine we
actually had race in case the cancellable was about to be reset or in
the middle of a cancellation.
In fact it could happen that when we released the mutex, another thread
could reset the cancellable just before the callback is actually called
and so leading to call it with g_cancellable_cancelled() == FALSE.
So to handle this, make disconnect and reset function to wait for
connection emission to finish, not to break their assumptions.
This can be tested using some "brute-force" tests where multiple threads
are racing to connect and disconnect while others are cancelling and
resetting a cancellable, ensuring that all works as we expect.
This solves problems with validating untrusted inputs from D-Bus, where
invalid numbers of added and removed menu entries, and positions, could
be specified.
Original patch from
https://bugzilla.gnome.org/show_bug.cgi?id=728733#c7, tweaked by Philip
Withnall to add a few code comments and make
`G_MENU_EXPORTER_MAX_SECTION_SIZE` public so callers can check their
inputs against it if they want. Also tweaked to use `g_warning()` instead
of the nonexistent `g_dbus_warning()`.
Fixes: #861
If it takes one more `GMainContext` cycle than expected for the
`activate` signals to be handled, the `GApplication` under test can be
released too early, and the test will fail due to not seeing a high
enough value of `n_activations`.
Hopefully avoid that by moving the release to a low priority idle
callback.
This fix is only hopeful because I’ve only been able to reproduce the
failure on FreeBSD CI and not locally.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2835
The timeout is just to stop the test hanging forever, so there’s no need
for it to be so short. It’s caused at least one spurious CI failure:
https://gitlab.gnome.org/GNOME/glib/-/jobs/2445023.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2837
GDesktopAppInfo never failed in the most simple of the cases: when a
desktop file or a command line app info was pointing to an invalid
executable (for the context).
The reason for this is that we're launching all the programs using
gio-launch-desktop which will always exist in a sane GLib installation,
and thus our call to execvp won't ever fail on failure.
This was partially mitigated by not allowing to create a desktop app
icon using a non-existent executable (even if not fully correctly) but
still did not work in case a custom PATH was provided in the launch
context.
To avoid this, use g_find_program_for_path() to find early if a program
that we're about to launch is available, and if it's not the case return
the same error that g_spawn_async_with_fds() would throw in such cases.
While this is slowing a bit our preparation phase, would avoid to leave
to the exec function the job to find where our program is.
Add tests simulating this behavior.
