The check was always failing because the code was comparing
the wrong strings. Reported in bug 605977.
(cherry picked from commit f2d8f6287d6e3fcb9e58402c2051d557f7e41632)
In the deserialise function, GUnixFDMessage was comparing 'level' to
both SOL_SOCKET and SCM_RIGHTS. It is correct to compare 'type' to
SCM_RIGHTS. The code passed tests only because:
1) it's a "should always be OK" double-check
2) SOL_SOCKET and SCM_RIGHTS, by chance, both have the value '1' on
Linux systems.
(cherry picked from commit baf20e09842a97c2d7925dff5ff9c6d35e36b27d)
An early exit in expand_application_parameters forgot to free
a GString. Reported by Steve Grubb.
(cherry picked from commit b00c6d7fb5798b4e528554e1221a553ab95506ed)
Not only is the default implementation broken (it causes infinite recursion
as seen in bug #603982), but its also worthless. If we just fall back on the
default stream operations we automatically get async version based on
the sync filter stream operations, which is what we want.
(cherry picked from commit 4fbbe190b7cbfd271bbb18428bc103ebffa41112)
Improve handling of g_file_query_default_handler() when called on an
invalid GFile (ie: one created with an invalid URI).
(cherry picked from commit 9681d7e75f2d1296a890bfa64b3478ea7025df62)
We used to pass the path for the symlink, but the device of the target
which is wrong and breaks metadata access.
https://bugzilla.gnome.org/show_bug.cgi?id=593809
(cherry picked from commit 2b2195bf68bf68837dc9f6b4765d3716694f42b3)
Since returning exactly one match has special significance, don't
give up matching before we've found at least 2 types. Also, make
sure that we don't return the same mime type more than once.
Bug 541236.
GWin32DirectoryMonitor was quite broken, but nobody had apparently
noticed, or at least not filed any bug. Only now with a bleeding edge
GTK+ file chooser does the code get exercised in common programs like
gtk-demo or GIMP, apparently. Bug #598899.
The source can be destroyed by the time we complete the result, and
then the g_source_get_context(current_source) call will cause
a critical error. We check for the source being destroyed and avoid
the check in that case.
This means we miss the right-thread check in this case, but thats
merely a helper, so this is not critical.
Metadata are really part of the pathname, not the target file
(as they are stored by pathname, and for many metadata like icon position
etc make not sense using the target data). So, even if nofollow
is not specified we should not follow links for metadata.
Ideally this should be implemented in the metadata extension in gvfs,
but the extension API does not allow this, so we do it in gio.
See https://bugzilla.gnome.org/show_bug.cgi?id=593809
g_network_address_address_enumerator_next_finish takes the first item of the
address list and moves the pointer to the next one, so we shouldn't do the same
in g_network_address_address_enumerator_next_async function
Fixes bug #593941
g_socket_send_message() and g_socket_send_to() fail with ENOBUFS or
EFAULT due to the fact that if no "address" argument is specified to
g_socket_send_message, when g_socket_send_message() calls sendmsg(2),
the 2nd parameter to sendmsg ("const struct msghdr *msg") contains
uninitialized values. The fix is simple - initialize msg.msg_name to
NULL and msg.msg_msg_namelen to 0.
https://bugzilla.gnome.org/show_bug.cgi?id=594759
This warning hits code that uses GSimpleAsyncResult outside of a
mainloop as a helper object. For instance EggDBus does this.
Since the bugs this warning would fix are pretty easy to spot
and since EggDBus is deployed already we just remove the
"called from outside main loop" warning.
However, we need to keep the "called from wrong context" warning
as that is very helpful when debugging misuse of the new multiple
main context code.
Previous code used g_mkstemp(). But when using
G_FILE_CREATE_REPLACE_DESTINATION, no attempt was made to ensure proper
mode and flags of the created temporary file. The visible issue was that
the file was always created with mode 0600 as opposed to using 0666.
(The invisible issue was that O_RDWR was used instead of O_WRONLY.)
