With 0d685b4946, we now encode resource
data as a string. Strings have trailing nul terminators. A C compiler
will happily ignore the fact that the nul terminator exceeds the stated
array length, and will drop it — but a C++ compiler won’t, and will
raise:
error: initializer-string for array of chars is too long [-fpermissive]
Fix that by increasing the array length by 1, and subtracting it again
in the GStaticResource struct.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This reverts commit 3c1902fcf9.
This was accidentally re-added from an old version of the branch before
!265 was merged. It should not have been re-added.
Rearrange the code so we try version 3 first,
falling back to version 2 and then version 1.
We still do a construct-time check to ensure
that we work with unsupported versions.
Note that this also takes care of setting the
initial property values in the version 1 case.
Version 3 of the network monitor portal interface adds
a CanReach method. Use it to implement can_reach.
The docs state that can_reach will either return TRUE
or set an error. So, set an error of G_IO_ERROR_HOST_UNREACHABLE
when the portal returns FALSE for CanReach.
GSettings XML schema files are installed in a well known directory
under Glib's installation directory: `glib-2.0/schemas`. However,
the Glib installation directory might vary, so the exact location of
the schema files might be unknown.
The information regarding this directory has been added to GIO's
pkg-config file, so it can be checked, and also overrided, by using
the command line utility.
The source callback for a GCancellable should have the cancellable itself
as first argument.
This was not the case, and when this code was hit, we were instead trying
to treat the pointer as a CommunicateState reference and thus wrongly
deferencing it, causing a memory error and a crash.
Some Testing revealed encoding resource data with string
escape codes to compile significantly quicker compared
to the same data encoded as an array with hexadecimal numbers.
See #1489
This is a follow-up to commit 614adf8a75,
which started generating two new files as part of the test; they need to
be cleaned up before distcheck will pass.
Ideally, the test should run a temporary directory and wipe that
directory itself before exiting, but that’s a bit of a big change to
make right now. Deferred to
https://gitlab.gnome.org/GNOME/glib/issues/1495.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In file gio/gtestdbus.c, function watch_parent, there is a loop which
waits for commands sent from the parent process and kills all processes
recorded in 'pids_to_kill' array on parent process exit. The detection
of parent process exit is done by calling g_poll and checking whether
the returned event is G_IO_HUP. However, 'revents' is a bit mask, and
we should use a bitwise-AND check instead of the equality check here.
It seems to work fine on Linux, but it fails on FreeBSD because the
g_poll returns both G_IO_IN and G_IO_HUP on pipe close. This means the
watcher process continues waiting for commands after the parent process
exit, and g_io_channel_read_line returns G_IO_STATUS_EOF with 'command'
set to NULL. Then the watcher process crashes with segfault when calling
sscanf because 'command' is NULL. Since the test result is already
reported by the parent process as 'OK', this kind of crash is likely to
be unnoticed unless someone checks dmesg messages after the test:
pid 57611 (defaultvalue), uid 1001: exited on signal 11
pid 57935 (actions), uid 1001: exited on signal 11
pid 57945 (gdbus-bz627724), uid 1001: exited on signal 11
pid 57952 (gdbus-connection), uid 1001: exited on signal 11
pid 57970 (gdbus-connection-lo), uid 1001: exited on signal 11
pid 57976 (gdbus-connection-sl), uid 1001: exited on signal 11
pid 58039 (gdbus-exit-on-close), uid 1001: exited on signal 11
pid 58043 (gdbus-exit-on-close), uid 1001: exited on signal 11
pid 58047 (gdbus-exit-on-close), uid 1001: exited on signal 11
pid 58051 (gdbus-exit-on-close), uid 1001: exited on signal 11
pid 58055 (gdbus-export), uid 1001: exited on signal 11
pid 58059 (gdbus-introspection), uid 1001: exited on signal 11
pid 58065 (gdbus-names), uid 1001: exited on signal 11
pid 58071 (gdbus-proxy), uid 1001: exited on signal 11
pid 58079 (gdbus-proxy-threads), uid 1001: exited on signal 11
pid 58083 (gdbus-proxy-well-kn), uid 1001: exited on signal 11
pid 58091 (gdbus-test-codegen), uid 1001: exited on signal 11
pid 58095 (gdbus-threading), uid 1001: exited on signal 11
pid 58104 (gmenumodel), uid 1001: exited on signal 11
pid 58108 (gnotification), uid 1001: exited on signal 11
pid 58112 (gdbus-test-codegen-), uid 1001: exited on signal 11
pid 58116 (gapplication), uid 1001: exited on signal 11
pid 58132 (dbus-appinfo), uid 1001: exited on signal 11
If the watcher process crashes before killing the dbus-daemon process
spawned by the parent process, the dbus-daemon process will keep running
after all tests complete. Due to the implementation of 'communicate'
function in Python subprocess, it causes meson to crash. 'communicate'
assumes the stdout and stderr pipes are closed when the child process
exits, but it is not true if processes forked by the child process
doesn't exit. It causes Python subprocess 'communicate' function to
block on the call to poll until the timeout expires even if the test
finishes in a few seconds. Meson assumes the timeout exception always
means the test is still running. It calls 'communicate' again and
crashes because pipes no longer exist.
https://gitlab.gnome.org/Infrastructure/GitLab/issues/286https://github.com/mesonbuild/meson/issues/3967https://bugs.python.org/issue30154
Previously, glocalfile.c would not set file system metadata for
the free/used key for file systems which reported 0 free space. This is
because some file systems don’t set that metadata when you call
statfs(), so we can’t reliably report it. However, some do, and they
can legitimately set f_bavail and f_bfree to 0 if the file system is
full.
In order to avoid that, always set the file system metadata unless the
file system is FUSE or ncpfs.
This is a partial revert of commit 0b9f24c1e1: instead of the changes
made in that commit, I think we should maintain a blacklist of file
systems which are known to not correctly report free space.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/328
Similar issue was fixed with commit f929d148, but it's happening again.
Define G_MESSAGES_DEBUG=all when running CI to ensure we won't regress
anymore.
In order to determine whether to trash a file to the home directory, we
compare its st_dev to our home directory's st_dev field.
This is the wrong thing to do on overlayfs when deleting files, because
st_dev contains the ID of the filesystem providing the file (which can
be the lower or upper filesystem), but directories always return the ID
of the overlayfs. Thus the comparison fails and we are unable to trash
the file.
Fix this by checking st_dev of the parent directory when we are deleting
a file.
Also adjust `test_trash_not_supported` for this - make its st_dev check
look at the parent directory's `st_dev` rather than the temporary file's
own.
Fixes#1027.
The documentation was unclear about what error codes would be returned
on attempting to open an empty or corrupt GVDB file. Previous versions
of the documentation incorrectly said that corrupt GVDB files were
considered equivalent to empty ones.
A recent commit has clarified the documentation to include its error
handling behaviour.
Update the two users of GVDB within GLib, GResource and GSettingsSource,
to follow this change, and add unit tests for them both.
Other users of the GVDB copylib will need to update their copy and make
appropriate changes if they have bugs in their handling of this
situation. dconf is one example of this. GVDB should be updated from
https://gitlab.gnome.org/GNOME/gvdb.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1454
While mountpoints are *not* symlinks, strictly speaking,
they works in a similar enough way, so consider them to be
symlinks for the purpose of querying local file info.
On Windows st_ctime field is the file creation time.
POSIX mandates that field to be the file state change time.
Naturally, glib code interpreted st_ctime as POSIX suggested,
and the result was bad.
Fix this by introducing special W32-only logic for setting
attributes from st_ctime field.
Fixes issue #1452.
We now send the fallback SCSV, meaning use of this function will cause
modern servers to immediately terminate the connection, so let's warn
API users to expect that behavior and be crystal clear that this
function should only be used as a fallback when a normal connection
attempt has already failed.
Also, the documentation is mostly duplicated between the property and
the function, so let's just reference the function documentation from
the property.
7efd76dd67 added these configure time tests to work around a bug
with older Android. Since the test didn't take Windows into account it
wrongfully applied the workaround on Windows too, breaking the build.
With meson this wasn't an issue since the check is skipped on Windows there
and our CI didn't catch this issue.
Change the test to run on Android only for meson and autotools.
This also makes it clear that the test+code can be dropped again if we stop
supporting older Android versions at some point.
GLib currently tries to use FAM volume monitor for monitoring files
within home on NFS. If FAM support is not available, it fallbacks by
default to GInotifyFileMonitor. I think we should fallback to
GPollFileMonitor instead, because inotify is not reliable on NFS,
which may cause issues for dconf. With this patch, it should be safe to
not build libgiofam and still be sure that dconf works properly if home
is mounted on NFS. I think this might be a first step to remove FAM
support from GLib completely, because gamin is buggy and dead for
several years already. Gamin just polls files on NFS anyway. This
change applies on files only, because GPollFileMonitor seems doesn't
support dirs, however it should be enough for dconf. The other
drawback is that one can't set poll timeout currently. Just a note
that this can still be overwritten by GIO_USE_FILE_MONITOR.
Releasing GVolumeMonitor before g_volume_mount finish cause that
g_volume_get_mount returns NULL, because the mount is not correctly
propagated to the volume.
https://gitlab.gnome.org/GNOME/glib/issues/1458
