The new "slowly add more task threads" code doesn't fully deal with
apps that queue lots and lots of tasks which then block on tasks from
their task threads. Fix this by bringing back the "task is blocking
other task" check and making sure that such tasks get bumped to the
front of the queue.
https://bugzilla.gnome.org/show_bug.cgi?id=687223
Recent changes to file monitors removed the delay before events were
reported. Among other things, this caused the trash backend of gvfs to
notice trashed files sooner than before.
On noticing trashed files, the backend tries to read the info file to
discover (among other things) the original location of the file.
Unfortunately, g_local_file_trash() does a strange dance when trashing a
file. It does a loop of open(O_EXCL) in order to file an empty filename
in the trash to write an info file to, trashes the file, and only then
writes the contents of the info file. This means that at the time the
file is moved to the trash, the info file is an empty stub.
Change the order so that we write out the actual content of the info
file first. If the actual trash files then we will unlink the info file
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=749314
Add string serialisation functions for GNetworkAddress, GSocketAddress,
GUnixSocketAddress, GInetSocketAddress, GNetworkService and
GSocketConnectable. These are intended for use in debug output, not for
serialisation in network or disc protocols.
They are implemented as a new virtual method on GSocketConnectable:
g_socket_connectable_to_string().
GInetSocketAddress and GUnixSocketAddress now implement
GSocketConnectable directly to implement to_string(). Previously they
implemented it via their abstract parent class, GSocketAddress.
https://bugzilla.gnome.org/show_bug.cgi?id=737116
GDatagramBased is an interface abstracting datagram-based communications
in the style of the Berkeley sockets API. It may be contrasted to (for
example) GIOStream, which supports only streaming I/O.
GDatagramBased allows socket-like communications to be done through any
object, not just a concrete GSocket (which wraps socket()).
This adds the GDatagramBased interface, and implements it in GSocket.
https://bugzilla.gnome.org/show_bug.cgi?id=697907
When G_OUTPUT_STREAM_CLOSE_TARGET is set,
g_output_stream_real_splice was not returning -1 in any error
cases, since the success flag was being overwritten.
https://bugzilla.gnome.org/show_bug.cgi?id=756255
The environment variable DISPLAY makes sense only for X11, it should
not be set in gio.
Beside, if the backend is not X11 but Wayland, forcing the value of
DISPLAY to the Wayland display will confuse the backend selection and
possibly crash the applications.
https://bugzilla.gnome.org/show_bug.cgi?id=754983
Commit a0cefc2217 introduced an unresolved
symbol, g_socket_send_message_with_timeout(), on win32. Windows
unfortunately isn’t clever enough to fill in the gaps and magic up the
implementation of that function from nowhere, so we had better do it
ourselves.
Factor the blocking behaviour out of g_socket_send_message() into a new
internal g_socket_send_message_with_timeout().
https://bugzilla.gnome.org/show_bug.cgi?id=756054
5d68947 factored out resuable items, but some of these are only for
*NIX builds, which will break the build on Windows. Fix this by
building these portions only when !G_OS_WIN32.
https://bugzilla.gnome.org/show_bug.cgi?id=756053
The value of g_socket_is_connected() gets stuck high if the GSocket is
shut down in two steps:
g_socket_shutdown (socket, TRUE, FALSE, NULL);
g_socket_shutdown (socket, FALSE, TRUE, NULL);
rather than one:
g_socket_shutdown (socket, TRUE, TRUE, NULL);
Fix that by tracking the connected status for the read half and the
write half of the connection separately.
https://bugzilla.gnome.org/show_bug.cgi?id=697907
set_auth_msg() was returning FALSE to indicate error, but all its
callers were expecting a negative return value to indicate error. This
was causing memory leaks for the GError, and errors to not be reported.
Coverity CID: 1325357
If the certificate constructor is called as:
g_tls_certificate_new_from_pem (data, length, NULL);
and PEM parsing fails for the private key, the function would have
continued to try and create a certificate using a NULL key_pem value,
which would have failed or crashed.
Use g_propagate_error() correctly to avoid this.
Coverity CID: 1325403
If an error in the underlying sendmmsg() syscall occurs after
successfully sending one or more messages, g_socket_send_messages()
should return the number of messages successfully sent, rather than an
error. This mirrors the documented sendmmsg() behaviour.
This is a slight behaviour change for g_socket_send_messages(), but as
it relaxes the error reporting (reporting errors in fewer situations
than before), it should not cause problems.
https://bugzilla.gnome.org/show_bug.cgi?id=751924
Add support for receiving multiple messages with a single system call,
using recvmmsg() if available. Otherwise, fall back to looping over
g_socket_receive_message().
This adds new API, g_socket_receive_messages(), and corresponding unit
tests.
https://bugzilla.gnome.org/show_bug.cgi?id=751924
In order to support per-operation timeouts on new API like
g_socket_receive_messages(), the internal GSocket API should use
timeouts rather than boolean blocking parameters.
(timeout == 0) === (blocking == FALSE)
(timeout == -1) === (blocking == TRUE)
(timeout > 0) === new behaviour
https://bugzilla.gnome.org/show_bug.cgi?id=751924
This complements the GOutputMessage struct. It will shortly be used for
adding a g_socket_receive_messages() function, but needs to be committed
first to allow some internal refactoring of GSocket.
https://bugzilla.gnome.org/show_bug.cgi?id=751924
Previously, GLib returned text/plain for empty files.
This is important because people may want to open empty (eg:
just-created) text files with the text editor.
An unintended side-effect of b6fc1df022
caused GLib to start returning application/octet-stream instead of
text/plain for these files.
This commit is essentially a revert of that commit, with a different
solution: we move the special-case up a bit in the function and
hard-code it to text/plain.
This change does not exactly maintain the old behaviour: previously, a
"fast" lookup would have returned application/octet-stream on an empty
file and now it will return text/plain. I consider this to be an
improvement (since we're returning better data) and don't expect it to
cause problems.
https://bugzilla.gnome.org/show_bug.cgi?id=755795
The API design here is a bit awkward — the in/out flags argument should
actually have been an in flags argument and an out msg_flags argument.
Clarify that a bit in the documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=751924
_wstat32i64() doesn't exist in msvcrt.dll. This doesn't cause a problem
on 32-bit Windows because mingw-w64 #defines _wstat32i64 to _wstati64,
but on 64-bit Windows we get a link error.
In addition, _wstat32i64() takes a struct _stat32i64 *, but
GLocalFileStat is #defined to struct _stati64, which is not the same
type on 64-bit Windows.
Fix by using _wstati64().
https://bugzilla.gnome.org/show_bug.cgi?id=749161
Make use of the common autotools module that is used to generate the MSVC
project files from their respective templates so that the main build files
beccome cleaner, and enhance them in a way that the headers that should be
installed can be written to the property sheets during 'make dist', so that
the chances of missing headers for MSVC builds can be greatly reduced.
Also use this autotools module to fill in the projects for
glib-compile-schemas and glib-compile-resources.
https://bugzilla.gnome.org/show_bug.cgi?id=735429
We don't need to run binaries we just built in order to successfully
build GLib and friends any more.
Since commit b74e2a7, we don't need to run glib-genmarshal when building
GIO; since commit f9eb9eed, all our tests (including the ones that do
need to run binaries we just built) are only built when running "make
check", instead of unconditionally at every build.
This means that we don't need to check for existing, native binaries
when cross-compiling, and fail the configuration step if they are not
found — which also means that you don't need to natively build GLib for
your toolchain, in order to cross-compile GLib.
We can also use the cross-compilation conditional, and skip those tests
that require a binary we just built in order to build.
https://bugzilla.gnome.org/show_bug.cgi?id=753745
GListStore already has a g_list_store_insert_sorted function,
which can be used to keep the list sorted according to a fixed
sort function. But if the sort function changes (as e.g. with
sort columns in a list UI), the entire list needs to be
resorted. In that case, you want g_list_store_sort().
https://bugzilla.gnome.org/show_bug.cgi?id=754152
Enhance GTestTlsBackend to allow setting the issuer property of
GTlsCertificates, and add a test to ensure certificate chain
construction with g_tls_certificate_new_from_pem() works as expected.
https://bugzilla.gnome.org/show_bug.cgi?id=754264
If a private key (or anything, in fact) follows the final certificate in
the file, certificate parsing will be aborted and only the first
certificate in the chain will be returned, with the private key not set.
Be tolerant of this, rather than expecting the final character in the
file to be the newline following the last certificate.
https://bugzilla.gnome.org/show_bug.cgi?id=754264
If @error is NULL then we don't even need to evaluate the remaining
arguments. And if errno is EWOULDBLOCK, then no one should see the
error message anyway, so don't bother g_strdup_printf'ing up a pretty
one.
https://bugzilla.gnome.org/show_bug.cgi?id=752769
If you called g_dbus_connection_remove_filter() on a filter while it
was running (or about to be run) in another thread, its GDestroyNotify
would be run immediately, potentially causing the filter thread to
crash.
Fix this by refcounting the filters, and using the existing mechanism
for running a GDestroyNotify in another thread in the case where the
the gdbus thread is the one that frees it.
Also, add a bit of documentation explaining this (and add a related
clarification to g_dbus_connection_signal_subscribe()).
https://bugzilla.gnome.org/show_bug.cgi?id=704568
This will prevent attempting to read from some files that appear normal but are
really device-like, such as those in /proc and /sys.
If we can't stat() the file then don't bother attempting to sniff, either.
https://bugzilla.gnome.org/show_bug.cgi?id=708525
FreeBSD and NetBSD have field st_birthtim and st_birthtime in struct stat,
respectively, which can be used to get file creation time on supported file
systems such as UFS2 and tmpfs.
https://bugzilla.gnome.org/show_bug.cgi?id=749492
gvfs commit b358ca "Make sure metadata is always returned by
query_writable_namespaces()" changed the
query_writable_namespaces vfunc to never return NULL, but the error
checking in g_daemon_file_query_writable_namespaces still assumes vfunc
failure implies NULL return value and GError set. This causes a memory
leak as on failure the GError will be set but the vfunc implementation
will have created its own default list so NULL will not be returned, and
the GError will never be cleared.
This commit directly checks if the GError is set to detect failures,
my_error is directly dereferenced in the error block anyway.
This also removes an unneeded call to g_file_attribute_info_new(); as
the vfunc always returns us a non-NULL GFileAttributeInfoList.
https://bugzilla.gnome.org/show_bug.cgi?id=747364
These tests clear up a misunderstanding of mine: Monitoring
nonexisting files and directories *does* work with the inotify
implementation, it just has a very long timeout for scanning
for missing locations, so the test needs to take that into
account.
This is meant for opaque, non-POSIX-like backends to indicate that the
URI is not persistent. Applications should look at
G_FILE_ATTRIBUTE_STANDARD_SYMLINK_TARGET for the persistent URI.
Examples of such backends could be a portal for letting sandboxed
applications access the file-system, or a database-backed storage like
Google Drive.
In these cases, the user visible file and folder names are different
from the real identifiers, used by the backend. So, a request to
create google-drive://user@gmail.com/foo/New\ File, would actually
lead to google-drive://user@gmail.com/foo/bar on the server even though
the user visible name is still "New File". Since the server-defined URI
is persistent and sanity-checked by the backend, it is recommended that
applications switch to it as soon as possible. Backends will try to
keep a mapping from "fake" to "real" URIs, but those are only on a
best effort basis. They might not be persistent or have the same
guarantees as the "real" URIs.
https://bugzilla.gnome.org/show_bug.cgi?id=741602
g_dbus_method_invocation_return_value(), etc, don't have GError
parameters (which makes sense since they won't usually return errors,
and there's not much you could do if they did), so in the rare case
when something does go wrong, they print a warning.
However, there is at least one situation where the warning is a bad
idea: if you are using private bus connections, and a client connects,
makes a request, and then disconnects before getting the response.
Given that there's nothing the caller can do to prevent this case from
getting hit (since the client might not disconnect until after the
call to g_dbus_method_invocation_return_value() starts) and given that
the server can never actually know for sure that the client has
received the response (it might disconnect after reading the response,
but before processing it), just kill the warning in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=753839
Add a new test which checks that atomically replacing a file that
is being monitored by GFileMonitor produced the expected events.
The test can easily be expanded to cover other file monitoring
scenarios.
After the big file monitoring rewrite, we only put the IN_MOVED_FROM event
in the queue for such pairs. It matches INOTIFY_DIR_MASK and thus we call
ip_dispatch_event on it, but that function was filtering it out because
the filename in the 'from' event is the one of the temp file, not the
one we are monitoring. That name is in the 'to' event, so compare it as
well, and let the event passin that case.
There is another instance of this check in glocalfilemonitor.c, which is
corrected here as well.
https://bugzilla.gnome.org/show_bug.cgi?id=751358
This is a binding-friendly version of g_dbus_connection_register_object.
Based on a patch by Martin Pitt and the code of g_bus_watch_name_with_closures.
https://bugzilla.gnome.org/show_bug.cgi?id=656325
exit-on-close for a DBus connection is a completely normal thing. On
a regular GNOME login, gdm retains the X server, but terminates the
session login bus and associated helpers like gnome-settings-dameon,
the a11y tools, etc.
I've seen several downstream reports of confusion as to what these
apparent error messages mean in the system log. It doesn't help
that they're so obtuse.
We're also printing them to stderr, when this is not an error.
The reason this was introduced is presumably some people were confused
as to why their process exited when the system bus did. But the
solution for that I believe is documentation, not printing stuff to
everyone's system log in normal operation.
https://bugzilla.gnome.org/show_bug.cgi?id=742386
The previous commit introduced a possible memory leak in cases
where we get a G_IO_ERROR_CLOSED error. Make sure to always
free an error, if we got one.
https://bugzilla.gnome.org/show_bug.cgi?id=753278
There are real world cases where emitting signals can fail, such
as if the DBus connection closes. Asserting and aborting the process
in these cases is just plain lazy.
Ignore the errors when the connection is closed, and turn the
others into warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=753278
Add a property to GNetworkMonitor indicating if the network
is metered, e.g. subject to limitations set by service providers.
The default value is FALSE
https://bugzilla.gnome.org/show_bug.cgi?id=750282
A signal accumulator can return TRUE to continue signal emission, and
FALSE to stop signal emission. handle-local-options callbacks can return
« return a non-negative option if you have handled your options and
want to exit the process ».
Currently, g_application_handle_local_options_accumulator (the
accumulator for the handle-local-options signal) returns TRUE on
non-negative return value (ie continue signal emission), and returns
FALSE on negative return values (ie when the default option processing
should continue).
This return value seems backward as on >= 0 values, subsequent
handle-local-options callbacks could overwrite the 'exit request' from
the handler, while on < 0 values, the handle-local-options processing
could end up early if several callbacks are listening for this signal.
In particular, the default handler for this signal
(g_application_real_handle_local_options) always returns -1 and will
overwrite >= 0 return values from other handlers.
This commit inverts the check so that signal emission stops early when
one of the handle-local-options callbacks indicates it wants processing
to stop and the process to exit.
https://bugzilla.gnome.org/show_bug.cgi?id=751598
We already have start, stop and is_active methods, but turning it
into a real property is useful for a few reasons:
- it allows us to bind the property to an UI or a setting
- it allows us to get notified when the state changes
- it allows us to instantiate objects directly in the stopped state
https://bugzilla.gnome.org/show_bug.cgi?id=752089
Also add g_app_info_get_fallback_for_type() and
g_app_info_get_recommended_for_type() as proxies for
g_app_info_get_all_for_type(), until gcontenttype support is improved.
This code was out of date with current coding practices.
Nowadays it's common to receive file descriptors over environment
variables from other processes like systemd. The unit files that
control these file descriptors are configurable by sysadmins.
It is not (necessarily) a programmer error when g_socket_details_from_fd()
is called with a file descriptor that is not a socket. It can also
be a system and/or configuration error.
https://bugzilla.gnome.org/show_bug.cgi?id=746339
In 4e7d22e268, deleting the file was moved
after the assertion which checks for the changed event that results from
it being deleted. This is the wrong way around and makes the assertion
fail.
Move the deletion back up before we check the condition. delete_app is
no longer an idle callback so it can be made void. The change
notification might come in when the loop isn't running now, so don't try
to quit if it isn't running. In this case we'll wait for the three
second timeout and the test will still pass.
https://bugzilla.gnome.org/show_bug.cgi?id=751737
When a task is cancelled, we want to move it to the front
of the queue - our sort function does that for us, but there
is no need to resort the entire queue here, we can just
move the one item and be done with it. This uses just-introduced
threadpool api for this purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=751160
Make sure to initialize the notification backend in
g_application_withdraw_notification() the same way as is done in
g_application_send_notification().
This makes it possible for an app to withdraw notifications it has sent
in a previous execution of the application.
https://bugzilla.gnome.org/show_bug.cgi?id=750625
We need to be more careful when we try to assign values to gpointers, so
that means we have to assign the value to the properly-dereference
gpointer, so that the assigned value will be retained after the function
returns. This code will be dropped soon, but it is done for XP
compatibility's sake for 2.44.
Should fix the issue reported in bug 730352 comment #24.
For performance reasons we should always try to send or
receive our messages first and only wait for more space
or data to become available if we get an EAGAIN (and
are in blocking mode).
https://bugzilla.gnome.org/show_bug.cgi?id=751122
This can be handy when you want to change the sense of a toggle
in the UI without rewriting the underlying logic. Currently, this
is just exposed as a construct-only property. We may add a
convenience wrapper or a special !property syntax for this later.
https://bugzilla.gnome.org/show_bug.cgi?id=728489
This is the right thing to do for the "a session is a user-session"
model implemented in dbus 1.9.14, which is described in
<http://lists.freedesktop.org/archives/dbus/2015-January/016522.html>.
It also resembles sd-bus' behaviour, although sd-bus will only try
kdbus and XDG_RUNTIME_DIR/bus, and never runs dbus-launch.
On systems following the more traditional "a session is a login-session"
model, X_R_D/bus won't exist, so it is harmless to check for it before
falling back to X11 autolaunching. Again, this matches the behaviour
of current libdbus and sd-bus versions.
Now that we do this, g_test_dbus_unset() needs to clear XDG_RUNTIME_DIR
as well as everything else.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=747941
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
This only alters what happens if we specifically connect to
"autolaunch:", for instance via "DBUS_SESSION_BUS_ADDRESS=autolaunch:".
We will still potentially try other platform-specific things if
DBUS_SESSION_BUS_ADDRESS is unset. There are currently no other
platform-specific things, so there is no practical difference yet,
but I'm about to add a more-preferred fallback path before autolaunch.
This matches libdbus' behaviour and the D-Bus Specification, in which
the autolaunch: transport specifically means X11 autolaunch
(as implemented by "dbus-launch --autolaunch") on Unix, or a
shared-memory-based protocol on Windows. Other platform-specific
transports or default/fallback modes, including launchd on Mac OS X
and XDG_RUNTIME_DIR/bus on Unix, are not part of "autolaunch:".
It's rather unfortunate that the same name means two different
platform-specific mechanisms, specific to different platforms -
if they were added today I'd call them x11: and windows-shm: or
something - but it's been like this since 2007 so it's too late now.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=747941
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Currently, applications using g_application_add_main_option_entries()
won't get translated entries in --help output. We need to call
g_option_group_set_translation_domain() with a NULL domain to ensure that the
default application gettext domain (ie the one passed to the
textdomain() call) will be used for the main entries passed by the
application.
If we want to allow more flexibility on which gettext domain should be
used for these entries, new API will be needed.
https://bugzilla.gnome.org/show_bug.cgi?id=750322
Add a new section to the main GSettings documentation which documents
the best practices for integrating GSettings into an autoconf/automake
build system using the GLIB_GSETTINGS macro.
Some of this material was adapted from the migrating-gconf.xml guide.
https://bugzilla.gnome.org/show_bug.cgi?id=741788
* Only check __OBJECT_ATTRIBUTES_DEFINED and __UNICODE_STRING_DEFINED
on MinGW (MSVC doesn't have these)
* MSVC: disable:4005 when including windows.h and ntstatus.h
* Move NTAPI cconv into the parens with the NtQueryKeyFunc
* Fix return values in some functions
https://bugzilla.gnome.org/show_bug.cgi?id=734888
- On first call scan the registry, collect information about URI protocols,
file extensions, applications and handlers, store that as a set of
interconnected structures in several hash tables
- Watch the registry keys, re-scan the registry when any one of them changes.
https://bugzilla.gnome.org/show_bug.cgi?id=666831
Use the newly added g_settings_schema_list_keys() API instead of
g_settings_list_keys() in order to list keys.
Doing this allows the 'list-keys' command to work without creating a
GSettings object, which is more efficient. It also means that we don't
have to provide a (meaningless and ignored) path when listing keys on
relocatable schemas.
While we're at it, update the 'range' command not to require creation of
a GSettings object, in a similar way.
https://bugzilla.gnome.org/show_bug.cgi?id=740308
The list of keys in a GSettings object depends entirely on the schema,
so it makes sense to expose this API there.
Move the implementation out of gsettings.c and into gsettingsschema.c,
replacing the earlier with a simple call to the new location.
We don't do the same for children because the children can change.
https://bugzilla.gnome.org/show_bug.cgi?id=740308
Cancellation of GPollFileMonitor is now handled correctly (in the sense
that no further signals will follow) but let's be extra paranoid and
disconnect our handler anyway, for good measure.
https://bugzilla.gnome.org/show_bug.cgi?id=739424
GPollFileMonitor emits CHANGES_DONE_HINT after CHANGED signals, but it
doesn't check to ensure that the file monitor wasn't cancelled before it
does that.
If the original signal caused the monitor to be unreffed, cancelled and
destroyed, we would still end up emitting an extra signal on it.
Avoid that by checking first for cancellation.
https://bugzilla.gnome.org/show_bug.cgi?id=739424
Removed all mentions of GLib file name encoding referring to
the environment strings. The env var content has no defined relation
to GLib's notion of filename encoding, or any encoding whatsoever.
It would be wrong to pass all UTF-8 strings through
g_filename_from_utf8() in order to put them into the environment,
for one thing.
https://bugzilla.gnome.org/show_bug.cgi?id=738185
DBus has recently introduced new message flag
DBUS_HEADER_FLAG_ALLOW_INTERACTIVE_AUTHORIZATION, which tells that
caller is willing to wait for unspecified amount of time for the call
to return, as the service may perform interactive authorization (e.g.
using polkit).
https://bugzilla.gnome.org/show_bug.cgi?id=739616
In order to maintain a logical stream of events, we need to make sure we
flush and queued change notifications before responding to any requests
for information from clients.
If we don't do this, it's possible that we emit an 'add' event that was
queued at the time of a 'DescribeAll' call _after_ the reply to that
call (which already contained the description of the new action).
In practice, this is not only logically incorrect, but it can also cause
problems. If a change to action 'state' or 'enabled' occurs after the
DescribeAll but before the signal has been dispatched, it will be
ignored because an 'add' signal is already pending. When that add
signal is sent, it will contain the correct data, but the receiver will
ignore it because it already saw the action in the DescribeAll reply.
https://bugzilla.gnome.org/show_bug.cgi?id=749693
