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
This is a hack for GLocalFileInfo to correctly get icons for directories.
Without this change content type for any W32 directory is NULL
(because there's no registry entry for "inode/directory" by default,
and in any way there's no file extension that means "directory" to put there),
and GLocalFileInfo uses content type to grab icons.
https://bugzilla.gnome.org/show_bug.cgi?id=748727
The code here was returning gtk-directory and similar names as
fallback, with a comment claiming that these are 'builtin gtk'.
But they aren't, anymore, so just return the standard names.
This code used to look at the SCM_CREDENTIALS and ignore every message
not from uid 0. However, when user namespaces are in use this does not
work, as if uid 0 is not mapped you get overflowuid instead. Right now
this means we ignore all messages in such user namespaces and glib
apps hang on startup.
We can't look at pids either, as pid 0 is returned for processes
outside your pid namespace.
Instead the correct approach is to look at the sending sockaddr and
if the port id (nl_pid) is zero, then its from the kernel.
Source:
http://lists.linuxfoundation.org/pipermail/containers/2015-May/036032.htmlhttps://bugzilla.gnome.org/show_bug.cgi?id=750203
Instead of just dropping address types that we're not specifically
handling we return a GNativeSocketAddress which is just a dummy
container for the stuct sockaddr.
https://bugzilla.gnome.org/show_bug.cgi?id=750203
GListStore requires that item-type be derived from GObject, so specify
that the type of the item parameters is GObject so the functions can be
used via gobject-introspection.
Add a scope parameter for the callback used during insert_sorted.
Previously, we waited up to 0.5s, but that can fail on slow
architectures like ARM; now we wait up to 60s in 0.1s increments.
Patch originally by Simon McVittie <simon.mcvittie@collabora.co.uk>,
modified by Iain Lane to be called earlier, to catch all testcases in a
particular test.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=724113
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Acked-by: Matthias Clasen <mclasen@redhat.com>
