The `gio move` tool has plenty of options, which are listed by
`gio help move`, however, the `man gio` page doesn't mention them.
Let's add these missing options to the man page as well.
It is expected that `g_file_move()` moves symlink file itself, not its
target. Unfortunately, copy and delete fallback passes `GFileCopyFlags`
and don't explicitly use `G_FILE_COPY_NOFOLLOW_SYMLINKS`. This may cause
that symlink target is copied and symlink itself is removed. Let's
explicitly pass `G_FILE_COPY_NOFOLLOW_SYMLINKS` to the copy operation to
prevent this unexpected behavior.
https://gitlab.gnome.org/GNOME/glib/issues/986
The `G_FILE_COPY_NOFOLLOW_SYMLINKS` flag doesn't make sense for move operation,
neither local implementation doesn't handle this flag in any way. Therefore
this paragraph should be removed from the docs (it was probably copy&pasted
from `g_file_copy()` docs by mistake).
Closes: https://gitlab.gnome.org/GNOME/glib/issues/986
Add a case for when the IPv6 result comes back negative and the IPv4
result is significantly delayed. This is exactly the case that causes
the bug addressed by GNOME/glib!865
The "happy eyeballs" RFC states that on receiving a negative response
for an IPv6 address lookup, we should wait for the IPv4 lookup to
complete and use any results we get from there.
The current code was not doing that: it was rather setting a timeout for
failing the resolution entirely. In scenarios where the IPv4 response
comes more than 50ms after the IPv6 response (which is easily attainable
under valgrind in certain configurations) this means that the IPv4
response will never come.
Remove the timeout and just wait.
See merge request GNOME/glib!865
The variable types for the PID (bp) and event (be) are accidentally
reversed in the test program. Correct their types so that tests do not
fail on Visual Studio x64 builds.
Fixes issue #1797
We already have the GType with which the GValue should be initialized,
so requiring an initialized GValue is not really necessary, and it
actually complicates code that wraps GObject, by requiring the retrieval
of the GParamSpec in order to get the property type. Additionally, it
introduces a mostly unnecessary g_value_reset().
We already changed g_object_getv() to allow passing uninitialized
GValues, but this fell through the cracks.
Closes: #737
In !863 I assumed that a 4 byte wchar_t would be equal to gunichar on all platforms,
but this is not the case for FreeBSD. It previously was using the non wchar_t based API
because it doesn't define __STDC_ISO_10646__.
Add back the __STDC_ISO_10646__ check again and introduce a more meaningful macro for guarding
the code paths that are mixing gunichar and wchar_t.
Fixes#1798
It’s already documented elsewhere, but not particularly obviously.
Clarify argument encodings in the GOptionArg documentation.
As reported on StackOverflow:
https://stackoverflow.com/q/56416098/2931197.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This was introduced in commit 7846d6154a: g_subprocess_get_identifier()
will return NULL after the subprocess has exited, and the subprocess in
the `noop` test will exit as soon as it has started spawning. So if the
scheduler scheduled the testprog subprocess quickly, descheduled the
parent test process until the testprog exited, then the return value
from g_subprocess_get_identifier() would be NULL.
Move the g_subprocess_get_identifier() test to one which calls testprog
in `sleep-forever` mode, since that is guaranteed not to exit until
killed (which we do later in the test).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The documentation erroneously said that a thread calling
g_rw_lock_reader_lock() would always block if another thread was waiting
for the write lock. That’s not true: if no thread holds the lock, it is
implementation defined which of a waiting reader and writer gets the
lock.
See
http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_rwlock_rdlock.html.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #590
The most useful ones were already listed in the pkg-config file, but
some others (notably, `gio-querymodules`) were not. List them in the
pkg-config file with their installed paths so that the right binary is
used if GIO is installed in a non-default path.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1796
`NM_STATE_CONNECTED_SITE` is documented to mean that a default route is
available, but that the internet connectivity check failed. A default
route being available is compatible with the documentation for
GNetworkMonitor:network-available, which should be true if the system
has a default route for at least one of IPv4 and IPv6.
https://developer.gnome.org/NetworkManager/stable/nm-dbus-types.html
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1788
More vectors will give an error and we can simply clamp here and
consider it like a short write instead.
In case of GSocketOutputStream this is done here instead of inside
GSocket before calling sendmsg() because we we can't generically handle
short writes when sending messages on a socket, e.g. for datagram
sockets this causes only part of the datagram to be sent and an error
would be more useful in this case than sending corrupted data.
Also reduce the fallback limit to 16 in gsocket.c as that's the minimum
value required by POSIX and add a static assertion that the limit is
never bigger than G_MAXINT as that's the type recvmmsg/sendmmsg take.
lconv 1.13 only supports gcc <=7 and lcov 1.14 supports <=8.
msys2 was just updated to gcc9, so this wont help with coverage support, but
it's a start I guess.
Queries the charset used by the associated console, which does not
necessarily match the charset of the current locale as returned by
g_get_charset.
Fixes https://gitlab.gnome.org/GNOME/glib/issues/1270
As we discovered in GNOME/gtk#1280, GCC considers the pragmas to control
the deprecation warnings as statements. This means we cannot just use
the GLib wrappers as markers around the call site, but we must be aware
of their side effects.
Let's document this, to avoid falling into the trap.
file_copy_fallback creates new files with default permissions and
set the correct permissions after the operation is finished. This
might cause that the files can be accessible by more users during
the operation than expected. Use G_FILE_CREATE_PRIVATE for the new
files to limit access to those files.
The code in gunicollate uses __STDC_ISO_10646__ to check that wchar.h is avilable,
that it includes the wide character related functions and that sizeof(wchar_t) == 4.
cygwin defines __STDC_ISO_10646__ and has sizeof(wchar_t) == 2 and the C standard text isn't
that clear on whether wchar_t should always be 4 bytes in this case, so we better not use if for
assuming the size here.
Instead of relying on __STDC_ISO_10646__ add HAVE_WCHAR_H and SIZEOF_WCHAR_T macros.
With HAVE_WCHAR_H defined we assume wchar_t exists and wchar.h exists. With SIZEOF_WCHAR_T we
guard the parts where the size of wchar_t is assumed to be 4 (currently all of them).
Note that this doesn't make the collate tests pass under cygwin, they fail before and after this patch for me.
See !755 for related discussions.
