The `g_file_trash` function fails with the `Unable to find or create trash
directory` error when the global `.Trash` directory exists. This is because
the commit 7f2af262 introduced the `gboolean success` variable to signalize
the detection of the trash folder, but didn't set it in all code branches.
Since for a time this variable was not initialized the bug wasn't visible
when the trash folder existed. The bug became effective after the `success`
variable was initialized with `FALSE` by the commit c983ded0. Let's explicitly
set the `success` variable in all branches to fix the global trash dir
detection.
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2439
This is necessary when building glib with icecc. Icecc splits the build
process into two parts. The file is locally preprocessed with
-fdirectives-only to resolve any includes. This adds linemarkers to the
intermediate file. Without the new-line at the end of the file this:
#include "gconstructor_as_data.h"
#include "glib/glib-private.h"
Is turned into this:
const char gconstructor_code[] = "...";# 1 "glib/glib-private.h"
...
The result is a compile error:
In file included from ../glib/gio/glib-compile-resources.c:45:
gio/gconstructor_as_data.h:1: error: stray '#' in program
gio/gconstructor_as_data.h:1: error: expected identifier or '(' before numeric constant
In file included from ../glib/glib/glib-private.h:22,
from gio/gconstructor_as_data.h:2,
from ../glib/gio/glib-compile-resources.c:45:
../glib/glib/gwakeup.h:27:1: error: unknown type name 'GWakeup'
../glib/glib/gwakeup.h:28:42: error: unknown type name 'GWakeup'
../glib/glib/gwakeup.h:30:42: error: unknown type name 'GWakeup'
../glib/glib/gwakeup.h:32:42: error: unknown type name 'GWakeup'
../glib/glib/gwakeup.h:33:42: error: unknown type name 'GWakeup'
In file included from gio/gconstructor_as_data.h:2,
from ../glib/gio/glib-compile-resources.c:45:
../glib/glib/glib-private.h:98:3: error: unknown type name 'GWakeup'
../glib/glib/glib-private.h:99:58: error: unknown type name 'GWakeup'
../glib/glib/glib-private.h💯58: error: unknown type name 'GWakeup'
../glib/glib/glib-private.h:102:58: error: unknown type name 'GWakeup'
../glib/glib/glib-private.h:103:58: error: unknown type name 'GWakeup'
In file included from gio/gconstructor_as_data.h:2,
from ../glib/gio/glib-compile-resources.c:45:
../glib/glib/glib-private.h:164:53: warning: file "../glib/gio/glib-compile-resources.c" linemarker ignored due to incorrect nesting
To avoid this, generate gconstructor_as_data.h with a new-line at the end
of the file.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
If `g_file_monitor_source_dispatch()` drops the last reference to its
`GLocalFileMonitor`, a deadlock will occur, because disposing the
`GLocalFileMonitor` causes synchronous disposal of the
`GFileMonitorSource`, and hence an attempt to re-lock the already-locked
mutex in the `GFileMonitorSource`.
Fix that by dropping the reference to the `GLocalFileMonitor` after
unlocking.
Diagnosed by Ting-Wei Lan. The bug was originally introduced by me in
commit 592a13b483.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Since commit 87e19535fe, the ETag check when writing out a file through
a symlink (following the symlink) has been incorrectly using the ETag
value of the symlink, rather than the target file. This is incorrect
because the ETag should represent the file content, not its metadata or
links to it.
Fix that, and add a unit test.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2417
This fixes a bug where the family flag was ignored in lookup_data_new,
causing the resolver to call getaddrinfo with no hints set when clearly
the family hint should have been set.
When using TAP we want every single line to be one of the following:
- a valid TAP clause
- a comment
- a blank line
Typical explicit test logs are single line comments, but in some cases
we might end up printing debug messages from libraries, and those may
contain multiple lines. When that happens, we break the TAP and fail the
test in conditions entirely outside of our control.
One option to avoid outright failure is to always prepend each line of a
messge with `#`, to ensure that the whole thing is considered a comment.
The code did not handle EOF (0 byte read) correctly. This can e.g. cause
an infinite loop if an incorrect socks proxy is configured.
Add the appropriate checks and return an G_IO_ERROR_CONNECTION_CLOSED
error if EOF is encountered.
It turns out that it is possible to use the Windows 8.0 SDK in Visual
Studio 2008 and 2010 officially, but requires a special setup in the
build command prompt.
Tell people how that special setup can be achieved, and restore the
extra instructions on building with Visual Studio 2008, as it is now
possible again.
The roapi.h that is included with the Windows 8.0 SDK mostly works under
plain C with one exception, so let people know the fix for that. Note
that the Windows 8.1 and 10 SDKs contain copies of roapi.h that is
directly usable under plain C.
If the same `GKeyFile` is reused to load multiple different key files,
any loads after the first which encounter translated keys will crash,
because clearing the data from the first load cleared the cached
language names, but didn’t clear `checked_locales`, so they were never
reloaded.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2361
It should not be possible for `->locales` to be set without
`->checked_locales` being set, so drop the redundant check. This helps
with branch code coverage.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
