When an URI to a symlink is added to the portal, we open it and we send
the FD (of the target) to the portal. This one has no clue about the original
symlink and so it mounts a file that is named like the target.
g_document_portal_add_documents(), however returns a path that contains
the original name and that one is what is sent to the applications when
used via GDesktopAppInfo.
Basically, this is the situation:
- /tmp/symlink -> /tmp/target
- An application is launched to open file:/tmp/symlink
- The portal creates file:/$XDG_RUNTIME_DIR/doc/ID/target
- Gio converts the path to file:/$XDG_RUNTIME_DIR/doc/ID/symlink
Now, since we can't just pass the symlink to the portal without also
changing the logic there, it's just better to do the conversion ourself,
and so, we use the already-opened fd to figure out the real path of the
opened file, and we return a document file URI that uses the target
basename instead
If the build/test machine is slow, heavily-loaded or otherwise
inconvenienced, it might take a few seconds for the signal to be sent
by the subprocess, received by the message bus, re-broadcasted by the
message bus and received by the test code. Wait a few more seconds
before giving up.
If this test is successful, increasing this timeout will not slow it
down: we stop waiting for the signal as soon as we receive it. This will
only make any difference if the test would have failed.
Signed-off-by: Simon McVittie <smcv@debian.org>
We have two things happening in parallel:
1. The GDBus worker thread writes out an AddMatch call to the socket,
the message bus reads that method call from the other end of the
socket, and the message bus responds by adding the match rule
for the signal subscription
2. The main thread forks, and the child execs
gdbus-connection-flush-helper, which sends the signal that we are
expecting; the message bus receives that signal, and broadcasts it
to subscribers, if any
Normally (1.) wins the race because exec'ing a child process is more
time-consuming than IPC, and the test passes.
However, it is possible for (2.) to win the race. If so, we will never
receive the expected signal (because it was received by the message bus
before the AddMatch() method call, so at the time it was received, the
test was not yet a subscriber); the test waits until the timeout and
then gives up, and the test fails.
For whatever reason, Debian's s390x buildd seems to be reliably failing
this test since this week, having previously passed. I don't know what
changed. I can (very rarely) reproduce the race condition described
above on a developer-accessible s390x machine by repeatedly running the
/gdbus/connection/flush test in a loop.
Bug-Debian: https://bugs.debian.org/1115617
Signed-off-by: Simon McVittie <smcv@debian.org>
With these adjustments, building with clang leads to no warnings:
- The "{ NULL }" statement could be replaced with "{ 0 }" to satisfy
clang, but this way it's explicitly filling all fields
- Even though "i" is not read with these g_array_binary_search calls,
it rightfully should be set
Currently, the `GDesktopAppInfo` constructors return an error if
validity checks for the `Exec=` line, or other lines, fail. However,
they were ignoring the validity checks done at the `GKeyFile` level, for
invalid UTF-8 or string escaping.
It seems consistent to error out for those too, rather than pretending
that the key file line wasn’t set at all (i.e. treating it like `NULL`).
Spotted by Daniel Kondor.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3771
In the case where mimeapps.list is a symlink, gio-issued updates would
overwrite the file, destroying the symlink in the process.
Instead, this approach recursively follows mimeapps.list symlinks
and overwites the contents of the final file instead.
Closes#3579
The Meson test harness handles that for us.
With a custom timeout, meson test -t is not useful (which is
surprising for users) and interactive debugging sessions may
terminate unexepectedly.
It’s possible for the server communications to finish one main context
iteration before all of the client communications, depending on how the
kernel queues socket connection messages.
Fixes CI failure: https://gitlab.gnome.org/GNOME/glib/-/jobs/5341950
```
GLib-GIO:ERROR:../gio/tests/socket-listener.c:639:test_accept_multi_simultaneously: 'clients[i].result' should not be NULL
not ok /socket-listener/accept/multi-simultaneously - GLib-GIO:ERROR:../gio/tests/socket-listener.c:639:test_accept_multi_simultaneously: 'clients[i].result' should not be NULL
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
As the new comments in the code try to explain, this fixes infinite
blocking which could happen when calling
`g_socket_listener_accept_async()` multiple times in parallel, with more
parallel calls than there are pending incoming connections on any of the
`GSocket`s in the `GSocketListener`.
The way `g_socket_listener_accept_async()` works is to create a set of
`GSocketSource`s when it’s called, one for each of the `GSocket`s in the
`GSocketListener`. Those sources are attached to the main context,
polling for `G_IO_IN` (indicating that the socket has a pending incoming
connection to accept).
When one of the socket sources polls ready, `g_socket_accept()` is
called on it, and a new connection is created.
If there are multiple pending `g_socket_listener_accept_async()` calls,
there are correspondingly multiple `GSocketSource` sources for each
`GSocket` in the `GSocketListener`. They will all poll ready in a single
`GMainContext` iteration. The first one to be dispatched will
successfully call `g_socket_accept()`, and subsequent ones to dispatch
will do likewise until there are no more pending incoming connections.
At that point, any remaining socket sources polling ready in that
`GMainContext` iteration will call `g_socket_accept()` on a socket which
is *not* ready to accept, and that will block indefinitely, because
`GSocket` has its own blocking layer on top of `poll()`.
This is not great.
It seems like a better approach would be to disable `GSocket`’s blocking
code, because `GSocketListener` is using `poll()` directly. We only need
one source of poll truth. So, do that.
Unfortunately, that’s complicated by the fact that
`g_socket_listener_add_socket()` allows third party code to provide its
own `GSocket`s to listen on. We probably can’t unilaterally change those
to non-blocking mode, so users of that API will get what they ask for.
That might include blocking indefinitely. I’ve adjusted the
documentation to mention that, at least.
The changes are fairly simple; the accompanying unit test is less
simple. Shrug. It tests for the scenario fixed by this commit, plus the
scenario fixed by the previous commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3739
As with the previous commit, but for `g_socket_connect()`, which is the
other cancellable use of `g_socket_condition_wait()` in the file.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Currently, if `g_socket_accept()` is called with a cancelled cancellable
and the socket is in non-blocking mode, `G_IO_ERROR_CANCELLED` is not
returned, because the cancellable is only checked in the call to
`g_socket_condition_wait()`, which only happens in blocking mode.
Fix that and add a unit test.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3739
It might be possible for the `low-memory-warning` signal to be emitted
(by the GLib worker thread) before the test has connected to it, which
could cause the tests to loop forever.
Potentially fixes
https://gitlab.gnome.org/pwithnall/glib/-/jobs/5322491, though I have
not been able to reproduce the race locally.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This will catch regressions like
fc030b2b64 if they happen again in future,
by testing that fallback argument parsing code path in
`g_application_run()`.
Heavily based on the PyGObject `test_local_and_remote_command_line` unit
test at
578a55982a/tests/test_gio.py (L289).
Thanks to Arjan Molenaar for investigating the failure and writing it
up in !4703.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The dbus-appinfo test was asserting that before_emit only happens
when we haven't seen a startup ID yet. But the docs imply that it
gets emitted for every activate/open/commandline, which may well
happen repeatedly. So drop this assertion.
Tests currently fail under macOS because the tool claims not to work
on apple devices. Since I cannot disprove this myself, I'm disabling the
tests on Darwin.
This introduces an integration test that executes gio launch from a
variety of working directories, and checks that %k is expanded to a
location that makes sense in the context of the executed program, i.e.
an absolute path.
`g_file_enumerator_finalize` should not call `g_file_enumerator_close`
because object parts (i.e. subclass variable and/or resources) might
already be freed, causing memory safety issues.
A better place to call `g_file_enumerator_close` is
`g_file_enumerator_dispose` because it is safe to access the object
memory here.
Fixes#3713
Signed-off-by: fbrouille <150549-fbrouille@users.noreply.gitlab.gnome.org>
Each enumerated address can be of a different family type, so you have to make a socket after you have that information.
As this is just a test client we make a new socket each time for simplicity.
This works around a Meson bug
(https://github.com/mesonbuild/meson/issues/4668).
If we have a Python test which spawns a built native binary, that binary is
listed in the `depends` argument of the `test()`. On Linux, this results in
the directories containing the built libraries which the binary depends on
being added to the `LD_LIBRARY_PATH` of the test invocation. On Windows,
however, Meson currently doesn’t add those directories to `PATH` (which is
the equivalent of `LD_LIBRARY_PATH`), so we have to do it manually.
This takes the same approach as Christoph Reiter did in
gobject-introspection
(13e8c7ff80/tests/meson.build (L2)).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Unlike the previous commit, there is no `g_fdopen()` wrapper where we
can add cross-platform support for this.
I’m not adding that now just for `O_CLOEXEC` support for these two
calls, so pass the flag locally for now.
If someone wanted to add a `g_fdopen()` wrapper in future, the
`GLIB_FD_CLOEXEC` here could be refactored easily.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This adds cross-platform support for it: on glibc, musl and BSD’s libc,
the flag is natively supported. On Windows, convert it to the `N` flag,
which similarly indicates that an open file shouldn’t be inherited by
child processes.
This allows us to unconditionally pass `e` to `g_fopen()` so `O_CLOEXEC`
can easily be set on its FDs.
Also do the same for `g_freopen()`, since it shares the same underlying
mode handling code.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Some apps names or keywords contain multiple words. For example 'LibreOffice
Calc' contains the word 'Calc'. This is rightfully detected as a prefix match,
however generally it is expected that searching for 'calc' would consistantly
return 'Calculator' in first position, instead of ranking them equally.
We now prioritise tokens that would otherwise rank equal based on where they
occur in the string, giving earlier occurences precedence.
The use case for exposing this field is GTK wanting reproducible
encoding output across different OSes.
I decided to expose the OS as an integer because zlib uses an int
in its header and does not make its OS codes available as a custom
type in its API.
I also decided to limit it to values between 0 and 255 because zlib
encodes the OS as a single byte.
Test included.
Fixes: #3663
We had code to avoid that we could call a toggle "up" notification
callback in locked state, but this was not covering the case in which
the cancellable second to last reference was removed in its cancellation
callback.
In fact, in such case we end up going from 2 -> 1 references during the
signal callback call and this leads to calling the toggle notify
callback in locked state.
To prevent this, add an even further reference before calling the
callback (in locked state, but there's no risk that a toggle-up
notification happens now), and drop it once unlocked again.
If when calling g_cancellable_connect() the cancellable was already
cancelled we could have ended up in calling the data cleanup
function while the cancellable lock was held.
This is likely not an issue, but it's still better not to do it,
so protect the code against it
