In the *_async_thread() functions, call the corresponding synchronous
function instead of calling the interface vfunc, which can be NULL.
In some cases the check for the vfunc == NULL was done, but to be
consistent it is better to always call the synchronous version (and the
code is simpler).
https://bugzilla.gnome.org/show_bug.cgi?id=548353
This feature is intended for clients that want to signal a desktop shell
their busy state, for instance because a long-running operation is
pending.
The API works in a similar way to g_application_hold and
g_application_release: applications can call g_application_mark_busy()
to increase a counter that will keep the application marked as busy
until the counter reaches zero again.
The busy state is exported read-only on the org.gtk.Application interface
for clients to use.
https://bugzilla.gnome.org/show_bug.cgi?id=672018
It is possible that the upstream servers return something, but
we then filter all results because they are of the wrong type.
In that case the API and subsequent GTask calls expect a GError
to be set.
https://bugzilla.gnome.org/show_bug.cgi?id=696857
to avoid warnings when built with -Wredundant-decls:
sessionmanager-presence-generated.c:316:1: warning: redundant redeclaration of ‘session_manager_presence_default_init’ [-Wredundant-decls]
sessionmanager-presence-generated.c:281:1: note: previous definition of ‘session_manager_presence_default_init’ was here
sessionmanager-presence-generated.c:1273:1: warning: redundant redeclaration of ‘object_default_init’ [-Wredundant-decls]
sessionmanager-presence-generated.c:1259:1: note: previous definition of ‘object_default_init’ was here
https://bugzilla.gnome.org/show_bug.cgi?id=696108
Expand and formalise the syntax for detailed action names, adding a
well-documented (and tested) public parser API for them.
Port the only GLib-based user of detailed action names to the new API:
g_menu_item_set_detailed_action(). The users in Gtk+ will also be
ported soon.
https://bugzilla.gnome.org/show_bug.cgi?id=688954
We need to close the stream *before* applying the file modes, because
g_file_replace() allocates a temporary file. At the moment we're
applying the modes to the extant file, then immediately rename()ing
over it with the default perms.
This regressed with commit 166766a89f.
The real fix here is to have g_file_create_with_info() so that we can
atomically create a file with the permissions we want.
https://bugzilla.gnome.org/show_bug.cgi?id=696014
_g_dbus_method_invocation_new is said to allow method_info == NULL,
but will crash inside g_dbus_method_info_ref when the method_info
really is NULL, because g_dbus_method_info_ref does not allow NULL as
parameter. Fixed by checking for NULL in _g_dbus_method_invocation_new
itself.
The leak itself happens because _g_dbus_method_invocation_new stores a
new reference to the method_info without also unreferencing it. Fixed
by adding the missing unref, protected by an if because the pointer
may be NULL.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=695376
We were using PATH_MAX to size a static array for reading lines from
the .hidden file. Some platforms (Hurd) don't declare a PATH_MAX.
Switch to using g_file_get_contents() and g_str_split('\n') instead.
Also take the time to clean up a bit with a switch to using a 'set mode'
GHashTable (since this code was originally written before we had those).
This patch is largely based on a patch from Emilio Pozuelo Monfort (who
also reported the bug).
https://bugzilla.gnome.org/show_bug.cgi?id=695147
Commit f641699 (for bug 675333) introduced a check whether the Exec= program in
a .desktop actually exists. This broke the /appinfo/mime/* test cases which use
executable names like "my_app".
Use real ones instead (like "echo" and "sleep"), and add a new
/appinfo/mime/ignore-nonexisting test case which verifies that
g_desktop_app_info_new() indeed ignores nonexisting executables.
https://bugzilla.gnome.org/show_bug.cgi?id=695191
Some (broken) toolchains for example trip up
-Werror=missing-prototypes in system headers. This patch allows
people to skip the formerly hardcoded "baseline" warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=694757
The documentation was suggesting that using G_APPLICATION_IS_SERVICE
would automatically set an inactivity timeout (ie: app stays around for
a while after the use count drops to zero).
In reality, it only adds an initial 10 second wait for the first
activation message to arrive after which it uses the normal inactivity
timeout mechanism.
Implement the g_network_monitor_can_reach_async() rather than falling
back to the default implementation, which calls the sync version (not
in a thread).
https://bugzilla.gnome.org/show_bug.cgi?id=694181
Enumerate the GSocketConnectable before checking for a default route.
For some connectable types this will involve a DNS lookup. This will
elminate false positives for hosts behind a VPN since DNS lookup will
fail if the VPN is not connected.
https://bugzilla.gnome.org/show_bug.cgi?id=694181
If the resolver reloads (ie, if /etc/resolv.conf changes),
GNetworkAddress needs to re-resolve its addresses the next time it's
enumerated. Otherwise hosts that have different IP addresses inside
and outside a VPN won't work correctly if you hold on to a
GNetworkAddress for them for a long time.
https://bugzilla.gnome.org/show_bug.cgi?id=694181
If a GNetworkAddress is created with a hostname like "fe80::xxx%em1",
make sure that the scope_id corresponding to "em1" is present in the
GSocketAddresses it returns when used as a GSocketConnectable.
https://bugzilla.gnome.org/show_bug.cgi?id=684404
Add GSimpleProxyResolver, for letting people do static proxy
resolution, and to use as a base class for other resolvers (such as
GProxyResolverGnome).
https://bugzilla.gnome.org/show_bug.cgi?id=691105
Add a proxy-resolver property to GSocketClient, to allow overriding
proxy resolution in situations where you need to force a particular
proxy rather than using the system defaults.
https://bugzilla.gnome.org/show_bug.cgi?id=691105
This is a GLib reimplementation of dbus_address_escape_value().
It's useful if you want to construct a D-Bus address from pieces:
for instance, if you have a listening Unix socket whose path is known,
and you want to connect a D-Bus peer to it.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=693673
Reviewed-by: Colin Walters <walters@verbum.org>
[amended to add Since: 2.36 as per review]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
If we don't connect to the control proxy's 'g-signal' signal, we won't have
'object-added' or 'object-removed' signals. So, connect to the 'g-signal' not
only when there already is a name-owner, but always.
https://bugzilla.gnome.org/show_bug.cgi?id=693285
While compiling, libtool will say that undefined symbols are not allowed, and
will refuse to make you a dll. This is only one line, easy to miss. And it
doesn't prevent `make' from completing successfully.
The code this patch adds is from other Makefile.am files that use
$(no_undefined). It's absence in gio is, most likely, an oversight.
Fixes#692058
The flowinfo and scope_id fields of struct sockaddr_in6 are in host
byte order, but the code previously assumed they were in network byte
order. Fix that.
This is an ABI-breaking change (since before you would have had to use
g_ntohl() and g_htonl() with them to get the correct values, and now
that would give the wrong values), but the previous behavior was
clearly wrong, and no one ever reported it, so it is likely that no
one was actually using it.
https://bugzilla.gnome.org/show_bug.cgi?id=684404
There are two benefits to this:
1) We can centralize any operating system specific knowledge of
close-vs-EINTR handling. For example, while on Linux we should never
retry, if someone cared enough later about HP-UX, they could come by
and change this one spot.
2) For places that do care about the return value and want to provide
the caller with a GError, this function makes it convenient to do so.
Note that gspawn.c had an incorrect EINTR loop-retry around close().
https://bugzilla.gnome.org/show_bug.cgi?id=682819
Ok, this function was just an awful mess before. Now the problem
domain is not trivial, and I won't claim this new code is *beautiful*,
but it should fix the bug at hand, and be somewhat less prone to
failure for the next person who tries to modify it. There's only one
unref call for each object now.
https://bugzilla.gnome.org/show_bug.cgi?id=692408
gio's glib-mkenums call needs to get gnetworking.h out of $(builddir),
not $(srcdir). Fix/simplify it by using $(filter) on $^ and letting
make find everything.
Also add -Wno-portability to AM_INIT_AUTOMAKE in configure.ac, so that
it doesn't warn about this (or about the gmake-specific features we
were already using in gio/tests/)
https://bugzilla.gnome.org/show_bug.cgi?id=691866
Use the same code GSocket does, to try SOCK_CLOEXEC first, and then
fall back to FD_CLOEXEC if it fails. (And fix that code to not call
fcntl if SOCK_CLOEXEC worked.)
https://bugzilla.gnome.org/show_bug.cgi?id=692332
When an error occurs while reading the file input stream in
g_file_load_contents (e.g. because the operation was cancelled), the
code is correctly calling g_task_return_error(), but in the callback
from the close operation, g_task_return_boolean() will be called again.
Code that cleans up its state in the async callback will then be called
twice, leading to invalid memory access.
https://bugzilla.gnome.org/show_bug.cgi?id=692202
Declare explicit support for monitor NFS from the fam file monitoring
backend. This will cause it to be preferred for monitoring on NFS, if
it is installed.
https://bugzilla.gnome.org/show_bug.cgi?id=592211
Add a pair of new extension points: 'gio-nfs-file-monitor' and
'gio-nfs-directory-monitor'.
Add a check to GLocalFile when creating a file monitor. If the
requested file is in the user's home directory and the user has an NFS
home directory then attempt to use an implementation of one of the new
extension points. If we don't have any implementations then fall back
to the normal "local" monitors.
https://bugzilla.gnome.org/show_bug.cgi?id=592211
Get rid of the complicated default module detection code in
GLocalFileMonitor and GLocalDirectoryMonitor and use the new
_gio_module_get_default_type() function instead.
This change also adds the ability to override the default file monitor
via the GIO_USE_FILE_MONITOR environment variable in the same way as can
be done for GIO_USE_VFS.
https://bugzilla.gnome.org/show_bug.cgi?id=592211
_gio_module_get_default() is a very convenient function for modules
implementing a singleton -- it finds the default module by priority
subject to override by a given environment variable name, instantiates
it, and caches the instance for future calls. It also has the ability
to query instances for being 'active' using a callback.
It doesn't work very well for non-singletons (like file monitors).
Add a new function _gio_module_get_default_type() that skips the
instantiation, returning the GType instead. As a replacement for the
'active' callback, a vtable offset can be given for a virtual function
to use to query if a particular backend is supported.
https://bugzilla.gnome.org/show_bug.cgi?id=592211
We have various sub directories in glib/ and gio/ (eg: inotify, gnulib,
pcre, xdgmime, etc.) that build convenience libraries that are then
included into libglib and libgio. The files in these directories need
to be built with the same visibility policy as the files in the first
level directories, so add CFLAGS for them all.
This wasn't a problem when the visibility flags were set directly in
CFLAGS but then we had to deal with some modules that we built that we
explicitly wanted to export symbols from.
For now, we can keep things the way they are because it's less hacky and
although it's a theoretical hazard to forget these CFLAGS, we rarely add
new subdirectories to the build.
Before this commit, the only difference between the expected and actual
ABI were the addition of _init and _fini symbols in each module (now
that regexp-based export control is not catching those).
Add read_async() and skip_async() tests to buffered-input-stream.
Fix and re-enable filter-streams's existing close_async() tests, and
add read_async(), skip_async(), and write_async() tests as well. Also,
redo the tests to use dummy GFilterInputStream and GFilterOutputStream
subclasses rather than GBufferedInput/OutputStream, so that we're
testing the base filter stream implementations of everything (since
the buffered stream overrides are already getting tested in the
buffered-input-stream and buffered-output-stream tests anyway).
Add a skip_async() test to unix-streams. (This one would crash without
the bugfix in the previous commit.)
skip_callback_wrapper expect the user_data (callback_data)
to be the task holding the task_data, not the task_data
itself.
Otherwise the task_data is cast as GTask and then task_data
is extracted from this bogus task.
https://bugzilla.gnome.org/show_bug.cgi?id=691812
We only want to control the default visibility for our five main
installable libraries: libglib, libgthread, libgmodule, libgobject,
libgio. We should therefore only set -fvisibility=hidden when building
those.
Use a separate substitution variable for this purpose.
Using CFLAGS directly leads to some modules built in testcases not
exporting their symbols (and then the tests fail). It also affects the
fam file monitoring module.
Colin had originally done it this way in his visibility patch series but
I failed to understand why so I didn't copy it. Now I do.
Also: revert changes made to two testcases in an attempt to work around
this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=691756
Add an #ifdef G_OS_UNIX around the GLIB_AVAILABLE_IN_ALL annotation on
the _get_type() functions for GLocal{File,Directory}Monitor.
These symbols are in private header files and are only exported so that
the in-tree file monitoring modules can subclass. This is only needed
on UNIX and was therefore never part of the public ABI on Windows.
Caught by Dieter Verfaillie.
One of our testcases builds a small giomodule for testing the loading of
modules containing resources. Unfortunately, this module gets built
using the same CFLAGS as the rest of GLib, including the visibility
flags (defaulting to hidden).
Use "config.h" to get a declaration of _GLIB_EXTERN that will export
symbols properly and use it to annotate the necessary APIs.
The kqueue file monitoring backend was misusing G_GNUC_INTERNAL for want
of 'static' in a couple of places and also using it to declare a lock
that was never used at all.
Fix those up.
With visibility now under the control of __declspec(dllexport) we no
longer need to build .def files or use them for building our various
.dll files.
.def files used to be installed (even though it is only really useful
when creating the .dll or .lib file). Don't do that anymore either.
The Makefiles still contain rules to create a .lib file for use with
Visual Studio and these rules require .def files. There are special
requirements to using these rules (like having installed and setup
Microsoft tools for use during the build) and therefore the problem of
creating a .def file for use with them is left open to anyone willing to
make the effort. Many options are available depending on which
toolchain is in use (dlltool, pexport, gendef, dumpbin.exe, just to name
a few).
If we can find a free tool for creating .lib files in the future, we
should probably revisit this issue and add proper support back to our
build system.
Add the GLIB_AVAILABLE_IN_ALL annotation to all old functions (that
haven't already been annotated with the GLIB_AVAILABLE_IN_* macros or a
deprecation macro).
If we discover in the future that we cannot use only one macro on
Windows, it will be an easy sed patch to fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=688681
glib-mkenums is not currently clever enough to know which version an
enum type was added in, so just mark all the _get_type() functions as
available in all versions.
https://bugzilla.gnome.org/show_bug.cgi?id=688681
This allows compilation with clang without errors, even when
-Wformat-nonliteral is active (as long as there are no real cases of
non literal formatting).
https://bugzilla.gnome.org/show_bug.cgi?id=691608
g_input_stream_real_skip_async() wants to use read_async() normally,
but will use skip() in a thread instead if it sees that read_async()
will end up using threads. Except that the test for "will read_async()
use threads" never got updated to know about the GPollableInputStream
support in read_async(), so it was doing the wrong thing in that case.
Fix.
Also remove a small bit of pre-GTask cruft noticed nearby.
https://bugzilla.gnome.org/show_bug.cgi?id=691489
For OSTree, I use Gio and also really care about performance. It's
disturbing to see open('.hidden') all over my straces and such. At
the moment I have an explicit set of things to query, as opposed to
"standard::*", since even before this that also implies an lstat() of
the parent directory.
This matches up with what we do for all the other attributes.
See https://bugzilla.gnome.org/show_bug.cgi?id=587806https://bugzilla.gnome.org/show_bug.cgi?id=691558
Since we're dynamically loading objects, after the g_type_init()
change, we now need to ensure people building with --as-needed don't
lose the DT_NEEDED on libgobject.
https://bugzilla.gnome.org/show_bug.cgi?id=691077
Some OS (e.g. OpenBSD) do not implement IP v4-mapped addresses. When
this is the case, then we get a "Connection refused", so force the test
to pass to that further tests can run.
https://bugzilla.gnome.org/show_bug.cgi?id=686058
The attached patch adds support for the btrfs "clone" ioctl which
makes Copy-on-Write reflinks, resulting in cheap O(1) copies when
source/destination are on the same filesystem. The ioctl itself is
quite straightforward, and GNU coreutils has had support since 7.5
(--reflink=auto --sparse=auto).
The ioctl only operates on regular files and symlinks, and always
follows symlinks; checks have been added accordingly.
This patch would be very useful for everyone who uses btrfs
filesystems (Meego folks for instance). On systems that don't have
btrfs, or if the the source is not on a btrfs filesystem, the ioctl
returns EINVAL, and the fallback code is triggered. Hence this will
cause no problems for non-btrfs users.
https://bugzilla.gnome.org/show_bug.cgi?id=626497
a5876e5f made GMemoryInputStream subclassable, but accidentally broke
read_async() and skip_async() in the process. The immediately
following e7983495 fixed read_async() (and added a test for it), but
skip_async() accidentally got... skipped.
Fix it now and add a test for it.
Also, GMemoryInputStream's skip_async() was assuming that skip() could
never fail, which is true of its own implementation, but might not be
true of a subclass's, so do proper GError handling too.
This will let us drop the dbus-python dependency.
The C version does not 100% reproduce all the hash table
and array manipulation of the python version, but the tests
do not rely on it anyway.
This greatly simplifies the test since everything is now in a single
process and possible bugs / quirks in libdbus-1 will not interfere
with the tests. On the other hand, we no longer test interoperability
with libdbus-1. This is somewhat moot, however, since other tests that
involve a message bus (e.g. GTestDBus users which include most of the
GDBus test suite itself) will test this.
Also ensure that we don't pollute existing D-Bus keyrings for the
DBUS_COOKIE_SHA1 authentication method (e.g. files in the
~/.dbus-keyrings directory) by setting the environment variables
G_DBUS_COOKIE_SHA1_KEYRING_DIR and
G_DBUS_COOKIE_SHA1_KEYRING_DIR_IGNORE_PERMISSION.
All in all, this change avoids some thorny issues where the GDBus and
libdbus-1 implementations disagree on whether an item in the D-Bus
keyring is still valid (items have an age etc.). In reality, since the
DBUS_COOKIE_SHA1 authentication method is never used in production,
this is never hit in production. This bug was, however, frequently hit
if you just ran the test suite repeatedly for 15 minutes or so.
Also add TODO items to mention that we currently don't test corner
cases involving
- DBUS_COOKIE_SHA1 timeouts
- libdbus-1 interoperability
Signed-off-by: David Zeuthen <zeuthen@gmail.com>
This DTD wasn't syntactically correct, and didn't actually
describe keys correctly. This change makes it a bit too lax,
but at least it can be used now.
https://bugzilla.gnome.org/show_bug.cgi?id=690538
This returns a GInputStream corresponding to the stdin on the
commandline that caused this invocation.
The local case works on both UNIX (GUnixInputStream on stdin) and
Windows (GWin32InputStream on GetStdHandle(STD_INPUT_HANDLE)). The
remote case works only on UNIX (by fd passing over D-Bus).
https://bugzilla.gnome.org/show_bug.cgi?id=668210
Add a new GFileMonitorFlag: G_FILE_MONITOR_WATCH_HARD_LINKS. When set,
changes made to the file via another hard link will be detected.
Implement the new flag for the inotify backend.
https://bugzilla.gnome.org/show_bug.cgi?id=532815
As RFC 2292 points out, some platforms (e.g. Darwin 9.8.0) provide
CMSG_FIRSTHDR(msg) which just returns msg.msg_control without first
checking if msg.msg_controllen is non-zero. We need a workaround for
such platforms not to let g_socket_receive_message() segfault.
https://bugzilla.gnome.org/show_bug.cgi?id=690388
If tasks block waiting for other tasks to complete then the system can
end up starved for threads. Avoid this by bumping up max-threads in
that case.
This also reverts 7b1f8c58 and reverts max-threads for GTask's
GThreadPool back to 10.
https://bugzilla.gnome.org/show_bug.cgi?id=687223
On IPv6 sockets, set both the IPv4 and IPv6 versions of IP socket
options, in case the socket is (or might become) IPv4-wrapped. (But
ignore errors when setting the IPv4 version.)
Similarly, when joining or leaving a multicast group, pick the sockopt
to use based on the address family of the multicast address rather
than the address family of the socket.
https://bugzilla.gnome.org/show_bug.cgi?id=687092
Since Windows builds by Visual C++ do not make use of autotools during
its build process, we need to dist a pre-configured
gio/gnetworking.h(.win32) for such builds.
The vs9/vs10 (and therefore vs11) property sheets are updated as well
https://bugzilla.gnome.org/show_bug.cgi?id=690163
This is a new convenience method designed to simplify some use
cases of GFileEnumerator, by making it easy to get the next file
from a file enumerator.
https://bugzilla.gnome.org/show_bug.cgi?id=690083
Add g_socket_get_option() and g_socket_set_option(), wrapping
getsockopt/setsockopt for the case of integer-valued options. Update
code to use these instead of the underlying calls.
https://bugzilla.gnome.org/show_bug.cgi?id=623187
Install a public "gnetworking.h" header that can be used to include
the relevant OS-dependent networking headers. This does not really
abstract away unix-vs-windows however; error codes, in particular,
are incompatible.
gnetworkingprivate.h now contains just a few internal URI-related
functions
Also add a g_networking_init() function to gnetworking.h, which can be
used to explicitly initialize OS-level networking, rather than having
that happen as a side-effect of registering GInetAddress.
https://bugzilla.gnome.org/show_bug.cgi?id=623187
Since there is only one resolver implementation now, we can move the
resolver utility functions from gresolver.c into gthreadedresolver.c,
and remove the prototypes from gnetworkingprivate.h.
https://bugzilla.gnome.org/show_bug.cgi?id=623187
The G_OBJECT_WARN_INVALID_PROPERTY_ID() macro uses a local variable
named "_object"; work around this by using "object" as the variable we
pass in.
https://bugzilla.gnome.org/show_bug.cgi?id=689377
This makes sure not to ifdef _g_io_win32_get_module() out when glib is
built as a static lib, and also fixes it to work when DllMain isn't
available.
The implementation uses GetModuleHandleEx() which is only available on
Windows XP and later, so this commit effectively drops the Windows 2000
support in glib. Earlier commit 731b4699 already took care of defining
_WIN32_WINNT to support the Windows XP API.
https://bugzilla.gnome.org/show_bug.cgi?id=675516
Now that we're directly accessing the memory holding a message blob,
we can access strings directly while reading them. This speeds up
read_string significantly, since we no longer malloc/memcpy/free.
The three processes this test creates need to be executed
in order, and g_usleep was used to guarantee that.
However, under heavy load, that is not enough. Instead,
wait until the children start by making sure they have
written to stdout before proceeding any further.
https://bugzilla.gnome.org/show_bug.cgi?id=664627
GData*Streams incur significant overhead, and we do not need all of the
functionality that they provide, since we only ever read from/write to
memory when handling message blobs, so it is more performant to use a
simple structure.
https://bugzilla.gnome.org/show_bug.cgi?id=652650
... and g_content_type_get_generic_icon_name(). The new functions are
implemented for Win32 since commit dace477c, so we no longer need to
guard them with G_OS_UNIX.
Really, the memory output stream API is too warped around the model
where it's a fixed size buffer that you've already allocated. Even in
C, I find myself always wanting to use it to just accumulate data into
an arbitrary-sized buffer it allocates.
Unfortunately, it's also not usable from bindings because it's not
common to bind g_free() and g_realloc(), but if you just pass NULL, you
get the default of a fixed size, which is useless as per above.
I am going to use this from a gjs test case, and the GSubprocess test
cases also will use it.
https://bugzilla.gnome.org/show_bug.cgi?id=688931
Add a pair of new APIs: one to GFile to create a new file from a
commandline arg relative to a given cwd and one to
GApplicationCommandLine to create a GFile from an arg, relative to the
cwd of the invoking commandline.
https://bugzilla.gnome.org/show_bug.cgi?id=689037
If we fail to start (and don't register() or call startup()) then also
don't call shutdown(). This happens in the case of failing to parse
commandline arguments, for example.
gnome-session needs to know the startup id that was given to
a started app; this was not available via GAppLaunchContext.
This commit adds a ::launched signal to get this information.
At the same time, turn the launch_failed vfunc into a signal
as well.
https://bugzilla.gnome.org/show_bug.cgi?id=688497
gnome-session still uses EggDesktopFile, since GDesktopAppInfo is
missing a handful of APIs that are needed to implement the
autostart spec. This patch adds the minimum that is required.
https://bugzilla.gnome.org/show_bug.cgi?id=688497
This reverts commit 85976cf91d and
properly removes the offending symbols from gio.symbols.
These two private symbols were found to be exported during Colin's
recent work cleaning up function visibility (among other things).
They were never exposed in any header file and I am 100% certain that
they have never been used by anybody. They were always private -- only
exposed on the library symbol list.
This change will cause ABI checking tools to complain that we have
removed functions, but the change is completely harmless for actual
applications.
https://bugzilla.gnome.org/show_bug.cgi?id=687441
MacOS provides the O_EVTONLY flag to open(2) which allow to open a file
for monitoring without preventing an unmount of the volume that contains
it.
https://bugzilla.gnome.org/show_bug.cgi?id=688518
Re-#define a few socket functions to work around winsock's prototypes
having, eg, "int *" rather than "unsigned int *", or "char *" rather
than "void *".
(Also fix two places that mistakenly assumed guint==guint32.)
https://bugzilla.gnome.org/show_bug.cgi?id=688109
GLocalFile was (in certain situations) translating a path like
"/foo/bar/baz" to "/foo\bar\baz" on win32. Fix it to make sure the
initial directory separator gets canonicalized too.
Fixes gio/tests/g-icon on win32.
https://bugzilla.gnome.org/show_bug.cgi?id=688109
Rather than defining _WIN32_WINNT only in a handful of files, define
it in config.h, like we do with _GNU_SOURCE.
(Also remove a "#define WIN32_LEAN_AND_MEAN" that isn't really all
that useful.)
https://bugzilla.gnome.org/show_bug.cgi?id=688109
Rather than using "extern" declarations of these win32 functions
everywhere they're needed, just prototype them in glib-private.h.
(Which also fixes the fact that they weren't prototyped in the files
where they're defined.)
https://bugzilla.gnome.org/show_bug.cgi?id=688109
Written by Dmitry Matveev as part of GSoC 2011:
http://netbsd-soc.sourceforge.net/projects/kqueue4gio/
This brings native file monitoring support on systems supporting kqueue(3)
(all BSDs) and remove the need to rely on the unmaintained gamin software.
The backend adds GKqueueDirectoryMonitor and GKqueueFileMonitor.
Some parts rewritten by myself (to prevent needing a configuration file).
Helpful inputs from Colin Walters and Simon McVittie.
https://bugzilla.gnome.org/show_bug.cgi?id=679793
$ sed -i s,determing,determining,g gio/gdrive.c
$ sed -i s,determing,determining,g gio/gdbusprivate.c
http://www.merriam-webster.com/dictionary/determining
For some reason according to `git log --follow` the whole file was created during some translation update.
commit c45b813504
Author: Timo Jyrinki <timo@debian.org>
Date: Mon Mar 12 11:02:04 2012 +0200
Finnish translation update from http://l10n.laxstrom.name/wiki/Gnome_3.4 translation sprint
Darwin's poll doesn't change revents if there are no available events, though it returns 0. Initialize the fd.revents to 0 so that the test passes.
That reveals a test failure, though, because with socket streams it takes time for an event to pass through the socket. Provide an 80-usec delay to allow time for the propagation.
We were passing the wrong destroy notify when returning the list of
records, so it would crash if it got called (ie, if you didn't call
g_resolver_lookup_records_finish()).
(Also fix s/targets/records/ throughout the records functions.)
These both existed in 2.34.1, but are not exposed in headers, and were
meant to be private. Making them static (in commit 84475e43) was
technically an ABI break, and in particular it causes abicheck.sh to fail.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=687441
Reviewed-by: Colin Walters <walters@verbum.org>
Even private functions that are actually called across compilation
units should have prototypes. For g_dbus_action_group_sync(), create
one in gdbusactiongroup-private.h
https://bugzilla.gnome.org/show_bug.cgi?id=687385
Add some extra protection when 'preparing' a group that doesn't yet
contain any menus. This can happen if you subscribe to a group that
doesn't yet exist.
It was possible to crash any application using
g_dbus_connection_export_menu_model() by requesting a non-existent
subscription group over the bus.
In practice this only happened in races -- where the proxy sees a group
that exists and queries it, but by the time it does, it's already gone.
https://bugzilla.gnome.org/show_bug.cgi?id=687089
Allow GDBusObjectManagerClient to work on peer to peer DBus
connections. Don't require that a unique bus name is available
for the object manager, if the owned bus name is NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=686920
When building the file attribute table info for local files, use
thumbnail paths in $XDG_CACHE_DIR/thumbnails/large in addition to
$XDG_CACHE_DIR/thumbnails/normal.
Failing to do this would cause an application that creates large
thumbnails by default to never find any value for
G_FILE_ATTRIBUTE_THUMBNAIL_PATH, with no
G_FILE_ATTRIBUTE_THUMBNAILING_FAILED set, which might cause the
application to either think thumbnailing is still in progress, or
blindly requeue thumbnail operations in a loop.
Large thumbnails are generally preferred, so we now default to the path
of a large thumbnail (in case both are present).
https://bugzilla.gnome.org/show_bug.cgi?id=686895
Sometimes the poll duration in the /socket/timed_wait test is slightly
bigger than the requested 100000, causing failures like:
GLib-GIO:ERROR:socket.c:620:test_timed_wait:
assertion failed (poll_duration < 110000): (110057 < 110000)
Adjust the test to allow some jitter in the "too high" direction.
https://bugzilla.gnome.org/show_bug.cgi?id=686458
GBusNameVanishedCallback is called with a NULL GDBusConnection in the
case that the connection has vanished. We were doing an assert to
verify that it was the same as we had exported the menu on and that
assert was failing.
https://bugzilla.gnome.org/show_bug.cgi?id=685995
Very many testcases, some GLib tools (resource compiler, etc) and
GApplication were calling g_type_init().
Remove those uses, as they are no longer required.
https://bugzilla.gnome.org/show_bug.cgi?id=686161
We were using the user-passed value of the @property argument for
several purposes in g_settings_bind(): error messages, binding
uniqueness (ie: one-binding-per-property-per-object) and most
importantly, connecting to the detailed notify:: signal.
The user may pass a string like "property_name" when the property's
canonical name is "property-name". g_object_class_find_property() will
find the property under these circumstances, but a connection to
"notify::property_name" will not notice notifies emitted for
"property-name".
We can solve this by using the user's string to perform the lookup and
then using pspec->name for everything after that.
https://bugzilla.gnome.org/show_bug.cgi?id=684882
Reimplement gioscheduler in terms of GTask, and deprecate the original
gioscheduler methods. Update docs to point people to GTask rather than
gioscheduler and GSimpleAsyncResult, but don't actually formally
deprecate GSimpleAsyncResult yet.
https://bugzilla.gnome.org/show_bug.cgi?id=661767
GTask is a replacement for GSimpleAsyncResult and GIOScheduler, that
also allows for making cancellable wrappers around non-cancellable
functions (as in GThreadedResolver).
https://bugzilla.gnome.org/show_bug.cgi?id=661767
This is the expected (and sane) behavior - without this bug-fix you'd
have to add "Since" to every member of a newly added D-Bus interface.
Also show-case this in the codegen example.
Signed-off-by: David Zeuthen <zeuthen@gmail.com>
The newly-introduced functions, g_content_type_get_symbolic_icon() and
g_content_type_get_generic_icon_name() don't seem to be for Windows, at
least for now. So filter them out from gio.symbols on Windows.
Also, glocalfileinfo.c calls g_content_type_get_symbolic_icon() in
get_icon(), so only build that code when on Unix, for the time being.
https://bugzilla.gnome.org/show_bug.cgi?id=684278
Adding the --sourcedir option fixes these:
/path/to/src/gio/tests/test2.gresource.xml: Error on line 5 char 1: Failed to locate 'test1.txt' in current directory.
/path/to/src/gio/tests/test3.gresource.xml: Error on line 5 char 1: Failed to locate 'test1.txt' in current directory.
/path/to/src/gio/tests/test4.gresource.xml: Error on line 5 char 1: Failed to locate 'test1.txt' in current directory.
/path/to/src/gio/tests/test.gresource.xml: Error on line 5 char 1: Failed to locate 'test1.txt' in current directory.
Some programs attempt to use libglib (or even libgio) when setuid.
For a long time, GTK+ simply aborted if launched in this
configuration, but we never had a real policy for GLib.
I'm not sure whether we should advertise such support. However, given
that there are real-world programs that do this currently, we can make
them safer with not too much effort.
Better to fix a problem caused by an interaction between two
components in *both* places if possible.
This patch adds a private function g_check_setuid() which is used to
first ensure we don't run an external dbus-launch binary if
DBUS_SESSION_BUS_ADDRESS isn't set.
Second, we also ensure the local VFS is used in this case. The
gdaemonvfs extension point will end up talking to the session bus
which is typically undesirable in a setuid context.
Implementing g_check_setuid() is interesting - whether or not we're
running in a privilege-escalated path is operating system specific.
Note that GTK+'s code to check euid versus uid worked historically on
Unix, more modern systems have filesystem capabilities and SELinux
domain transitions, neither of which are captured by the uid
comparison.
On Linux/glibc, the way this works is that the kernel sets an
AT_SECURE flag in the ELF auxiliary vector, and glibc looks for it on
startup. If found, then glibc sets a public-but-undocumented
__libc_enable_secure variable which we can use. Unfortunately, while
it *previously* worked to check this variable, a combination of newer
binutils and RPM break it:
http://www.openwall.com/lists/owl-dev/2012/08/14/1
So for now on Linux/glibc, we fall back to the historical Unix version
until we get glibc fixed.
On some BSD variants, there is a issetugid() function. On other Unix
variants, we fall back to what GTK+ has been doing.
Reported-By: Sebastian Krahmer <krahmer@suse.de>
Signed-off-by: Colin Walters <walters@verbum.org>
g_dbus_connection_call_with_unix_fd_list_sync () and
g_dbus_connection_call_sync () should allow None for the
bus_name parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=683771
Signed-off-by: Richard Hughes <richard@hughsie.com>
The test was assuming that all cancelled ops would finish within a
certain amount of time, but this often failed under valgrind. Instead,
just run the loop until all of the ops have actually finished.
https://bugzilla.gnome.org/show_bug.cgi?id=682560
If the interface given cannot be matched, `iface_obj' was left uninitialized and
the iface_obj == None check would end up crashing:
Traceback (most recent call last):
File "/usr/bin/gdbus-codegen", line 41, in <module>
sys.exit(codegen_main.codegen_main())
File "/usr/lib64/gdbus-2.0/codegen/codegen_main.py", line 175, in codegen_main
apply_annotations(all_ifaces, opts.annotate)
File "/usr/lib64/gdbus-2.0/codegen/codegen_main.py", line 146, in apply_annotations
apply_annotation(iface_list, iface, None, None, None, None, key, value)
File "/usr/lib64/gdbus-2.0/codegen/codegen_main.py", line 64, in apply_annotation
if iface_obj == None:
UnboundLocalError: local variable 'iface_obj' referenced before assignment
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=683088
On slower platforms, the overhead of the 240 D-BUS Sleep calls is larger than
the current maximum of 6 seconds. A run on a Panda board sometimes fails with
ERROR:/build/buildd/glib2.0-2.33.8/./gio/tests/gdbus-threading.c:409:test_method_calls_on_proxy:
assertion failed (elapsed_msec < 6000): (7365 < 6000)
Bump maximum time to 8 seconds to be more resilient to this.
https://bugzilla.gnome.org/show_bug.cgi?id=682222
Because it now handles EINTR. And we should do so. While most people
use Linux, which tries very hard to avoid propagating EINTR back up
into userspace, it can still happen.
https://bugzilla.gnome.org/show_bug.cgi?id=682833
The async test had several problems:
- It created a proxy and did not launch a main loop, meaning that its
callback would usually not get called, or, if it did get called, the
test harness would have taken down the connection already, causing an
assertion failure when the proxy had an error.
- It was dependent on the proxy test to set up the server and would fail
because some properties were modified by that test.
https://bugzilla.gnome.org/show_bug.cgi?id=674805
* In order to add contstruct properties to an abstract base
calls, and retain ABI stability, the base class must add a
default implementation of those properties.
* We cannot add a default implementation of certificate-bytes
or private-key-bytes since certificate and private-key properties
are writable on construct-only.
This reverts commit 541c985869.
https://bugzilla.gnome.org/show_bug.cgi?id=682081
There was a /* XXX */ in the code here to do proper typechecking of the
GVariant in the menu model when using g_menu_model_get_item_attribute().
We have g_variant_check_format_string() now, so use it.
Implement test case suggested by Ryan Lortie on bug:
https://bugzilla.gnome.org/show_bug.cgi?id=679288
"There is a potential race here that's really unlikely to happen, but
here we go: We are trying to read from the same socket in two threads.
Some data comes. That causes the poll() in both threads (above) to
finish running. Then the cancellable is checked above. We now find
ourselves here. Only one thread will read the data. The other will
block on this function. Then the user may cancel the cancellable while
we are blocked here, but we will stay blocked...."
If a named pipe is being read in message mode and the next message is
longer than the nNumberOfBytesToRead parameter specifies, ReadFile
returns FALSE and GetLastError returns ERROR_MORE_DATA.
Since the API doesn't allow to return both a GError and the number of
bytes read so far, it makes more sense to return nread, and let the
client call GetLastError() himself to check if ERROR_MORE_DATA.
The current alternative loses the nread information.
https://bugzilla.gnome.org/show_bug.cgi?id=679288
Any file handle created with FLAG_OVERLAPPED must have
ReadFile()/WriteFile() called with an OVERLAPPED structure.
Failing to do so will give unspecified results, invalid read/write or
corruption.
Without FLAG_OVERLAPPED, it is not possible to read and write
concurrently, even with two seperate threads, created by 2 input and
output gio streams. Also, only with FLAG_OVERLAPPED may an IO
operation be asynchronous and thus be cancellable.
We may want to call ReOpenFile() to make sure the FLAG is set, but
this API is only available since Vista+.
According to MSDN doc, adding the OVERLAPPED argument for IO operation
on handles without FLAG_OVERLAPPED is allowed, and indeed the existing
test still passes.
v2:
- update GetLastError() after _g_win32_overlap_wait_result ()
- split the unrelated ERROR_MORE_DATA handling
https://bugzilla.gnome.org/show_bug.cgi?id=679288
