Two of the vfuncs in GMountOperation need some annotations for their
element types and array sizes, otherwise g-ir-scanner comes up with
nonsense output.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=773980
Bug #786580 triggered this warning to show up in the appinfo tests if
run on a machine where no terminal except xterm is installed (for
example, a build machine). Since we didn’t warn before if xterm but no
other terminals were installed, it seems reasonable to downgrade the
warning to a debug message.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790914
If we can’t convert the inotify event mask into a GFileMonitorEvent enum
value, don’t propagate it to GLocalFileMonitor, since it hits an
assertion failure in that case.
This should no longer be possible since the previous commit to ignore
IN_Q_OVERFLOW events, but we might as well change this just in case
other bugs crop up in event mask handling.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=776147
There’s not much we can do about them, and if they go unhandled, they
can propagate through to g_file_monitor_source_handle_event() and cause
assertion failures due to not mapping to a GFileMonitorEvent.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=776147
That event is deprecated, and the kqueue backend can’t provide enough
information to go alongside the event (i.e. the name of the new file).
Use G_FILE_MONITOR_EVENT_DELETED instead.
Quite disappointed in the kqueue documentation for this: I cannot find a
single piece of documentation or example about how NOTE_RENAME is
supposed to communicate the new name of the file.
If it turns out that this is possible, the code can be amended again in
future. At least now it doesn’t abort.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=776147
While gio module extension is loaded a new GProxyResolverPortal is
created to query whether it's supported. We always return FALSE when not
aunder flatpak, so we don't need to connect to the session bus in that
case. Add a helper ensure_resolver_proxy() that returns TRUE when the
proxy is created and use it in is_supported() instead of creating the
proxy unconditionally in the instance initialization.
https://bugzilla.gnome.org/show_bug.cgi?id=790894
fstype is a const char*, and is passed to
g_file_info_set_attribute_string(), which takes a copy of it. There’s no
need to g_strdup() the FS type from various statfs/statvfs buffers
beforehand, given that the buffers are valid for the duration of this
function.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=679347
This adds g_file_load_bytes() to make it more convenient to
load the contents of a GFile as GBytes.
It includes a special casing for gresources to increase the
chances that the GBytes directly references the embedded data
instead of copying to the heap.
https://bugzilla.gnome.org/show_bug.cgi?id=790272
In the vast majority of cases, we can avoid temporary
allocations for paths in g_resources_enumerate_children().
In the case we need to add a suffix "/", we can usually just
build the path on the stack. In other cases, we can completely
avoid the strdup, which appears to only have been added for
readability. If the path is really long, we fallback to doing
what we did before, and use g_strconcat().
In the case of Builder, this saved 5.3mb of temporary
allocations in the process of showing the first application
window.
https://bugzilla.gnome.org/show_bug.cgi?id=790275
Previously, the path canonicalization for resources had liberal use of
strlen() and memmove() while walking through the path. This patch avoids
any secondary strlen() and removes all use of memmove().
A single allocation is created up front as we should only ever need one
additional byte more than then length of the incoming path string.
To keep the implementation readable, the mechanics are kept in external
functions. memrchr() was not used due to its lack of portability.
This is faster in every test case I've tested. Paths that contain
relative ../ have the most speedup.
https://bugzilla.gnome.org/show_bug.cgi?id=790310
The Python version was added for the Meson build, but we might as well
use it from autotools too, since it does exactly the same thing as the
Perl version (modulo not including a trailing linebreak, but that
doesn’t matter).
Works fine with Python 2.7 or Python 3.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790147
This will fix a few broken links in the documentation, and shut up a
load of gtk-doc warnings (but certainly not all of them).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790015
Uris may be altered by the following code, which breaks xdg-open:
file = g_file_new_for_commandline_arg (arg[i])
uri = g_file_get_uri (file);
Examples of possible uri changes:
mailto:email -> mailto:///email
magnet:?xt=urn:hash -> magnet:///?xt=urn:hash
ssh://user@host -> sftp://user@host
This patch causes that uris aren't preprocessed for locations with
scheme, however absolute and relative paths are still preprocessed.
https://bugzilla.gnome.org/show_bug.cgi?id=779182
create_cstr_from_cfstring_with_fallback() is allowed to be called when str == NULL
but create_cstr_from_cfstring() isn't which leads to warnings in the console.
Fix this by adding NULL checks into create_cstr_from_cfstring_with_fallback().
https://bugzilla.gnome.org/show_bug.cgi?id=788936
The patch basically just grabs the implementation of g_content_type_get_icon_internal()
from gcontenttype.c - the only difference is that it first converts UTI to MIME using
g_content_type_get_mime_type() and at the end frees this temporary MIME type.
https://bugzilla.gnome.org/show_bug.cgi?id=788936
This commit adds new W32-only functions to gstdio.c,
and a new header file, gstdioprivate.h.
These functions are:
g_win32_stat_utf8()
g_win32_lstat_utf8()
g_win32_fstat()
and they fill a private structure, GWin32PrivateStat,
which has all the fields that normal stat has, as well as some
extras.
These functions are then used throughout glib and gio to get better
data about the system. Specifically:
* Full, 64-bit size, guaranteed (g_stat() is forced to use 32-bit st_size)
* Full, 64-bit file identifier (st_ino is 0 when normal stat() is used, and still is)
* W32 File attributes (which stat() doesn't report); in particular, this allows
symlinks to be correctly identified
* Full, 64-bit time, guaranteed (g_stat() uses 32-bit st_*time on 32-bit Windows)
* Allocated file size (as a W32 replacement for the missing st_blocks)
st_mode remains unchanged (thus, no S_ISLNK), so when these are given back to
glib users (via g_stat(), for example, which is now implemented by calling g_win32_stat_utf8),
this field does not contain anything unexpected.
g_lstat() now calls g_win32_lstat_utf8(), which works on symlinks the way it's supposed to.
Also adds the g_win32_readlink_utf8() function, which behaves like readlink()
(including its inability to return 0-terminated strings and inability to say how large
the output buffer should be; these limitations are purely for compatibility with
existing glib code).
Thus, symlink support should now be much better, although far from being complete.
A new W32-only test in gio/tests/file.c highlights the following features:
* allocated size
* 64-bit time
* unique file IDs
https://bugzilla.gnome.org/show_bug.cgi?id=788180
The GAsyncResult documentation didn't specify the context in which the
GAsyncReadyCallback is expected to be invoked. Since asynchronous
operations can be implemented in various ways involving GSources,
threads and coroutines, it is useful to mention what the standard
expections are.
Unfortunately, since this was left undefined for so long, we can only
phrase it as a suggestion, and not as a hard requirement.
https://bugzilla.gnome.org/show_bug.cgi?id=783825
Where we were already treating GHashTables as sets, modify them to use
the set-specific APIs g_hash_table_add() and g_hash_table_contains(), to
make that usage more obvious and less prone to being broken.
Heavily based on patches by Garrett Regier <garrettregier@gmail.com>.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=749371
