This reverts commit 4cad66580b.
Downgrading the criticals was only temporary. Now we’ve branched for
GLib 2.78, the criticals can be reinstated early this cycle, so people
have the maximum time to fix latent bugs in their code.
Fixes: #2951
This partially reverts ed8e86a7d4.
The change to add the criticals (commit ed8e86a7d4) is correct, but
landed too late in the cycle. Let’s downgrade the criticals to debugs
for now, to stop applications seeing a lot of new criticals in their
output. Those criticals are particularly disruptive for command line
applications and unit tests.
Early in the next cycle, the debugs will be re-upgraded to criticals.
This will give applications a whole additional cycle to fix their
ambiguous use of API.
It turned out that a lot of applications have latent bugs around
calling `g_file_info_get_*()` without checking whether an attribute
is set first, and were hence relying on the ‘unknown’ return value
also being an appropriate default for them.
This was compounded by the fact that several non-local GVFS backends
were not setting `GFileInfo` attributes all the time, which caused the
‘missing attribute’ code path to be hit more frequently. For example,
they would only call `g_file_info_set_is_hidden()` with a true value and
never bother with a false one.
It was further compounded by the fact that, while this change landed for
the 2.75.4 release, there did not seem to be extensive integration
testing of that release, and distributions and downstreams went straight
to 2.76.0. That meant we missed the window between 2.75.4 and 2.76.0 to
change, fix or revert this behaviour. GLib relies on distros and
downstreams doing integration testing of unstable releases. We test with
downstream GNOME as part of gnome-build-meta, but do not have the
resources to do integration testing for everybody.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
See: #2907
See: #2932
See: #2934
See: #2945
See: #2948
Before commit ed8e86a7d4, this function would have silently returned a
zero-valued `GTimeVal` if the correct attributes weren’t present.
That partially regressed in commit ed8e86a7d4, which made it return with
a critical warning, but without zeroing the `GTimeVal`. The critical
warning can be ignored by users (it doesn’t abort the process unless
`G_DEBUG=fatal-criticals` is set), but the change in behaviour of
zeroing the `GTimeVal` could cause bugs.
See: #2907
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
As documented in a previous commit, these functions should not be called
without the right attributes being present in the `GFileInfo`. Add
critical warnings to make this more obvious.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2907
It doesn’t make sense to (for example) call `g_file_info_get_name()` if
the `GFileInfo` doesn’t contain `G_FILE_ATTRIBUTE_STANDARD_NAME`, given
that building the `GFileInfo` is typically a static process and entirely
under the control of the programmer.
By being this restrictive, we avoid having to return ‘unknown’ values
for some of these standard APIs, particularly the numeric ones such as
`g_file_info_get_size()`. If APIs like that were to work correctly in
the face of a `GFileInfo` without `G_FILE_ATTRIBUTE_STANDARD_SIZE`
specified, they’d have to be able to return a value to indicate the
attribute is missing. Returning `0` or `G_MAXSIZE` to indicate that
would be ambiguous.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2907
Some applications (eg., gnome-photos) really want a large thumbnail,
if one can be created. Simply falling back to a smaller one (probably
created by an old nautilus), without giving the application a chance
to create a bigger thumbnail, is undesirable because they will appear
fuzzy.
Therefore, at separate attribute sets for all the thumbnail sizes
that are supported in the spec: normal/large/x-large/xx-large.
The old attribute will now return by default the biggest available, as
it used to be, but also including the x-large and xx-large cases.
Co-Authored-by: Marco Trevisan <mail@3v1n0.net>
Fixes: #621
This introduces no functional changes but will make refactoring a bit
easier in the following commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Add SPDX license (but not copyright) headers to all files which follow a
certain pattern in their existing non-machine-readable header comment.
This commit was entirely generated using the command:
```
git ls-files gio/*.[ch] | xargs perl -0777 -pi -e 's/\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/\n \*\n \* SPDX-License-Identifier: LGPL-2.1-or-later\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/igs'
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
gio/gfileinfo.c: In function ‘g_file_info_remove_attribute’:
gio/gfileinfo.c:706:9: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
706 | if (i < info->attributes->len &&
| ^
Fix signedness warning in gio/gfileinfo.c:g_file_info_create_value()
gio/gfileinfo.c: In function ‘g_file_info_create_value’:
gio/gfileinfo.c:1084:9: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
1084 | if (i < info->attributes->len &&
| ^
Fix signedness warning in gio/gfileinfo.c:matcher_matches_id()
gio/gfileinfo.c: In function ‘matcher_matches_id’:
gio/gfileinfo.c:2624:21: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
2624 | for (i = 0; i < matcher->sub_matchers->len; i++)
| ^
Fix signedness warnings in gio/gfileinfo.c:g_file_attribute_matcher_enumerate_namespace()
gio/gfileinfo.c: In function ‘g_file_attribute_matcher_enumerate_namespace’:
gio/gfileinfo.c:2713:21: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
2713 | for (i = 0; i < matcher->sub_matchers->len; i++)
| ^
gio/gfileinfo.c:2715:27: error: comparison of integer expressions of different signedness: ‘guint32’ {aka ‘unsigned int’} and ‘int’
2715 | if (sub_matchers[i].id == ns_id)
| ^~
Fix signedness warning in gio/gfileinfo.c:g_file_attribute_matcher_enumerate_next()
gio/gfileinfo.c: In function ‘g_file_attribute_matcher_enumerate_next’:
../glib.git/gio/gfileinfo.c:2752:13: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’} [-Werror=sign-compare]
2752 | if (i < matcher->sub_matchers->len)
| ^
gio/gfileinfo.c: In function ‘g_file_info_list_attributes’:
gio/gfileinfo.c:645:17: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
645 | for (i = 0; i < info->attributes->len; i++)
| ^
gio/gfileinfo.c: In function ‘g_file_info_has_namespace’:
gio/gfileinfo.c:610:17: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
610 | for (i = 0; i < info->attributes->len; i++)
| ^
gio/gfileinfo.c: In function ‘g_file_info_find_value’:
gio/gfileinfo.c:543:9: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
543 | if (i < info->attributes->len &&
| ^
gio/gfileinfo.c: In function ‘g_file_info_clear_status’:
gio/gfileinfo.c:499:17: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
499 | for (i = 0; i < info->attributes->len; i++)
| ^
gio/gfileinfo.c: In function ‘g_file_info_set_attribute_mask’:
gio/gfileinfo.c:453:21: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
453 | for (i = 0; i < info->attributes->len; i++)
| ^
gio/gfileinfo.c: In function ‘g_file_info_copy_into’:
gio/gfileinfo.c:385:17: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
385 | for (i = 0; i < dest_info->attributes->len; i++)
| ^
gio/gfileinfo.c: In function ‘g_file_info_finalize’:
gio/gfileinfo.c:327:17: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
327 | for (i = 0; i < info->attributes->len; i++)
| ^
This was mostly machine generated with the following command:
```
codespell \
--builtin clear,rare,usage \
--skip './po/*' --skip './.git/*' --skip './NEWS*' \
--write-changes .
```
using the latest git version of `codespell` as per [these
instructions](https://github.com/codespell-project/codespell#user-content-updating).
Then I manually checked each change using `git add -p`, made a few
manual fixups and dropped a load of incorrect changes.
There are still some outdated or loaded terms used in GLib, mostly to do
with git branch terminology. They will need to be changed later as part
of a wider migration of git terminology.
If I’ve missed anything, please file an issue!
Signed-off-by: Philip Withnall <withnall@endlessm.com>
g_date_time_add_seconds() and g_date_time_add_full() use floating-point
seconds, which can result in the value varying slightly from what's
actually on disk. This causes intermittent test failures in
gio/tests/g-file-info.c on Debian i386, where we set a file's mtime
to be 50µs later, then read it back and sometimes find that it is only
49µs later than the previous value.
I've only seen this happen on i386, which means it might be to do with
different floating-point rounding when a value is stored in the 80-bit
legacy floating point registers rather than in double precision.
g_date_time_add() takes a GTimeSpan, which is in microseconds;
conveniently, that's exactly what we get from the GFileInfo.
Bug-Debian: https://bugs.debian.org/941547
Signed-off-by: Simon McVittie <smcv@collabora.com>
The actual parameter name in g_file_attribute_matcher_new()
attributes, so change the param reference to match. This way,
doc tools can create a proper link.
g_file_info_set_modification_time() and
g_file_info_set_modification_date_time() set the
G_FILE_ATTRIBUTE_TIME_MODIFIED_USEC attribute in addition to
G_FILE_ATTRIBUTE_TIME_MODIFIED, so microsecond precision is available
when provided by the caller, so mention both attributes in the docs.
When future porting deprecated code to use
g_file_info_get_modification_date_time() we risk a number of breakages
because the current implementation also requires the additional use of
G_FILE_ATTRIBUTE_TIME_MODIFIED_USEC. This handles that situation gracefully
and returns a GDateTime with less precision.
Applications that want the additional precision, are already using the
additional attribute.
(Minor tweaks by Philip Withnall.)
They use the deprecated GTimeVal type, which is not year 2038 safe, so
have to be deprecated.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1438
These are alternatives to g_file_info_{get,set}_modification_time(),
which will soon be deprecated due to using the deprecated GTimeVal
type, which is not year 2038 safe.
The new APIs take a GDateTime instead.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1438
G_FILE_ATTRIBUTE_DOS_IS_MOUNTPOINT allows mountpoints
(NTFS reparse points with IO_REPARSE_TAG_MOUNT_POINT tag) to
be told apart from symlinks (NTFS reparse points with
IO_REPARSE_TAG_SYMLINK tag), even though both are reported
by glib as "symlinks".
G_FILE_ATTRIBUTE_DOS_REPARSE_POINT_TAG allows the exact
reparse tag value to be obtained by the user. This way
even more exotic reparse points can be identified and
handled by the user (glib itself currently has no code
to work with any reparse points that are not symlinks
or mountpoints).
It's unnecessary, and only adds visual noise; we have been fairly
inconsistent in the past, but the semi-colon-less version clearly
dominates in the code base.
https://bugzilla.gnome.org/show_bug.cgi?id=669355
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
