It was previously 4KiB, but this isn’t enough for sniffing the
content-type of some GPT disk images (they use 4KiB sectors, and the
magic bytes are in the second sector). A buffer of 8KiB would work,
but 16KiB seems harmless and more future proof.
Most of the time, the buffer size should be set by xdgmime anyway, based
on the largest sniff buffer its database needs. Currently (with
shared-mime-info master) that’s 18730 bytes, so even with a 16KiB buffer
we’re going to potentially mis-identify a few file types.
Tested manually by modifying the example GPT image from shared-mime-info
(https://gitlab.freedesktop.org/xdg/shared-mime-info/-/blob/master/tests/mime-detection/disk.gpt)
to remove the magic at offset 0x200 and add it instead at offset 0x1000,
then running:
```
cp shared-mime-info.git/tests/mime-detection/disk.gpt ./disk-without-extension
gio info -a standard::content-type ./disk-without-extension
```
It should print `application/vnd.efi.img` rather than
`application/octet-stream`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3186
When setting the file time using utimensat, don't ignore
microseconds for access/modify times. By doing that, they're preserved
when using g_file_info_set_modification_date_time and then setting the file's
attributes from it.
Fixes#3116
`_g_stat_has_field (statbuf, G_LOCAL_FILE_STAT_FIELD_ATIME)` will always
return `TRUE` on Windows (since it uses a basic `struct stat`), so the
platform-inspecific code is equivalent to the Windows-specific code.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
`GLocalFileStat` is a platform-specific abstraction around `struct stat`
or `struct statx`. If `struct statx` is available, it will use that by
preference as it has more features.
`glocalfileinfo.c` was, in some places, incorrectly accessing the fields
of `GLocalFileStat` directly rather than through its `_g_stat_*()`
getters. While it correctly accounted for the platform-specific
differences between `st_mtimensec` and `st_mtim.tv_nsec`, it hadn’t been
updated to deal with `stx_mtime`.
On Android, `st_mtimensec` is defined as a fallback for
`st_mtim.tv_nsec` (even though it doesn’t need to be). This caused GLib
to take the `st_mtimensec` code path rather than the `stx_mtime` code
path, and hence try to dereference `st_mtim` in a `struct statx`.
Fix that by correctly using the `_g_stat_*()` getters consistently.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3039
Previously it was only being set on non-Windows platforms. For
consistency, always set it on Windows too.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2934
Following on from #2907, set various boolean attributes if they have
been requested, or are known for sure, and their value is `FALSE`.
Previously the `FALSE` value would have been implicitly returned by the
getter function, but now doing that without the attribute being
explicitly set will trigger a critical warning.
*Don’t* set these attributes if their value is unknown or there was an
error querying it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2934
The `is-backup` attribute isn't currently set on Windows. It would
be nice to set such basic attributes on all platforms. Let's set
the attribute to `FALSE` there.
Currently, the `G_FILE_ATTRIBUTE_STANDARD_IS_BACKUP` attribute is set
only when its value is `TRUE`. This is wrong with the latest changes as
the `GLib-GIO-CRITICAL **: 00:54:07.260: GFileInfo created without
standard::is-backup` errors are printed now from the
`g_file_info_get_is_backup` function among others. Let's set this
aattribute also when it is `FALSE`.
Related: https://gitlab.gnome.org/GNOME/glib/-/issues/2934
The lost+found dir isn't detected as hidden currently. This is regression
caused by the commit 728ad64b. Let's change the code a bit to be sure that
the lost+found dir is marked as hidden again.
Don’t just set them when they’re true and rely on their non-presence
being evaluated to `FALSE`. That means that they erroneously don’t get
returned in `g_file_info_list_attributes()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2907
Fix a regression that appeared after adding support for nanosecond
timestamps to set_mtime_atime(). User-visible effect: when copying a
file from a gvfs MTP mountpoint to the local filesystem, the file's
mtime is set to 0.
This behavior happens when setting G_FILE_ATTRIBUTE_TIME_MODIFIED first,
then G_FILE_ATTRIBUTE_TIME_MODIFIED_USEC. Setting the second attribute
ends up in set_mtime_atime() with mtime_usec_value set, and mtime_value
== NULL. When mtime_value is NULL, the tv_sec part of the timestamp
should be fetched by lazy_stat(), but set_mtime_atime() fails to assign
it properly, and tv_sec stays at 0, leading to losing the main part of
the timestamp.
Fix the issue by setting times_n[1].tv_sec to the value fetched from
lazy_stat().
Fixes: b33ef610de ("Add functionality to preserve nanosecond timestamps")
Fixes: 15cb123c82 ("glocalfileinfo: don't call both utimes and utimensat")
Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com>
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
That’s what xdgmime uses for zero-sized files (see `XDG_MIME_TYPE_EMPTY`).
Historically, GLib explicitly used `text/plain` for empty files, to
ensure they would open in a text editor. But `text/plain` is not really
correct for an empty file: the content isn’t text because there is no
content. The file could eventually become something else when written
to.
Text editors which want to be opened for new, empty files should add
`application/x-zerosize` to their list of supported content types.
Users who want to set a handler for `application/x-zerosize` on their
desktop should use
```sh
gio mime application/x-zerosize # to see the current handler
gio mime application/x-zerosize org.gnome.gedit.desktop # to set it
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2777
`HAVE_COCOA` should be used only in the places where we’re actually
depending on the Cocoa toolkit. It should not be used as a general way
of detecting building on a Darwin-based OS such as macOS.
Conversely, there are a few places in the code where we do want to
specifically detect the Cocoa toolkit (and others where we specifically
want to detect Carbon), so keep `HAVE_COCOA` and `HAVE_CARBON` around.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2802
This reverts commit 476e33c3f3.
We’ve decided to remove `G_OS_DARWIN` in favour of recommending people
use `__APPLE__` instead. As per the discussion on #2802 and linked
issues,
* Adding a new define shifts the complexity from “which of these
platform-provided defines do I use” to “which platform-provided
defines does G_OS_DARWIN use”
* There should ideally be no cases where a user of GLib has to use
their own platform-specific code, since GLib should be providing
appropriate abstractions
* Providing a single `G_OS_DARWIN` to cover all Apple products (macOS
and iOS) hides the complexity of what the user is actually testing:
are they testing for the Mach kernel, the Carbon and/or Cocoa user
space toolkits, macOS vs iOS vs tvOS, etc
Helps: #2802
In case the XDG database is not initialized yet we may try to sniff a
0-length data, making our content-type routines to mark non-empty files
as `application/x-zerosize`.
This is wrong, so in case the sniff size is not set, let's just
try to read the default value. To avoid false-application/x-zerosize
results (that are not something we want as per legacy assumptions).
See: https://bugzilla.gnome.org/show_bug.cgi?id=755795
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2742
Use a similar behaviour as the utime()/posix implementation and query
the current times to allow modifying only usec/nsecs parts.
Fixes tests/g-file-info on win32.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
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
This fixes a scan-build warning:
```
../../../../source/glib/gio/glocalfileinfo.c:1661:28: warning: Although the value stored to 'mydirname' is used in the enclosing expression, the value is never actually read from 'mydirname' [deadcode.DeadStores]
mydirname = g_strdup (dirname),
^ ~~~~~~~~~~~~~~~~~~
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1767
The function which calls `SetFileTime()` works with seconds and
nanosecond, but the functions which call it are doing so with seconds
and microseconds.
Fix them so they convert to nanoseconds first.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The code appears to be dealing with time in units of 100ns, not 100µs,
so name the variable accordingly.
The rest of the arithmetic in that function appears consistent and
correct.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
gio/glocalfileinfo.c: In function ‘get_access_rights’:
gio/glocalfileinfo.c:932:9: error: comparison of integer expressions of different signedness: ‘uid_t’ {aka ‘unsigned int’} and ‘int’
932 | uid == parent_info->owner ||
| ^~
gio/glocalfileinfo.c: In function ‘read_link’:
gio/glocalfileinfo.c:188:21: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
188 | if (read_size < size)
| ^
From:
9eb9c93275
"we found that the const security_context_t declarations in libselinux
are incorrect; const char * was intended, but const security_context_t
translates to char * const and triggers warnings on passing const char *
from the caller. Easiest fix is to replace them all with const char *."
And later marked deprecated in commit:
7a124ca275
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
As hidden file caches currently work, every look up on a directory caches
its .hidden file contents, and sets a 5s timeout to prune the directory
from the cache.
This creates a problem for usecases like Tracker Miners, which is in the
business of inspecting as many files as possible from as many directories
as possible in the shortest time possible. One timeout is created for each
directory, which possibly means gobbling thousands of entries in the hidden
file cache. This adds as many GSources to the glib worker thread, with the
involved CPU overhead in iterating those in its main context.
To fix this, use a unique timeout that will keep running until the cache
is empty. This will keep the overhead constant with many files/folders
being queried.
Some filesystems don't have meaningful access times under at least some
circumstances (see #2189, #2205). In this situation the traditional stat()
and related kernel interfaces have to put something meaningless in the
st_atime field, and have no way to signal that it is meaningless.
However, statx() does have a way to signal that the atime is meaningless:
if the filesystem doesn't provide a useful access time, it will unset
the STATX_ATIME bit (as well as filling in the same meaningless value
for the stx_atime field that stat() would have used, for compatibility).
We don't actually *need* the atime, so never include it in the required
mask. This was already done for one code path in commit 6fc143bb
"gio: Allow no atime from statx" to fix#2189, but other callers were
left unchanged in that commit, and receive the same change here.
It is not actually guaranteed that *any* of the flags in the
returned stx_mask will be set (the only guarantee is that items in
STATX_BASIC_STATS have at least a harmless compatibility value, even if
their corresponding flag is cleared), so it might be better to follow
this up by removing the concept of the required mask entirely. However,
as of Linux 5.8 it looks as though STATX_ATIME is the only flag in
STATX_BASIC_STATS that might be cleared in practice, so this simpler
change fixes the immediate regression.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2205
Signed-off-by: Simon McVittie <smcv@collabora.com>
statx does not provide stx_atime when querying a file in a read-only
mounted file system. So call to statx should not expect it to be in
the mask. Otherwise we would fail with ERANGE for querying any file in
a read-only file system.
Fixes#2189.
If `statx()` is supported, query it for the file creation time and use
that if returned.
Incorporating some minor code rearrangement by Philip Withnall
<withnall@endlessm.com>.
Fixes: #1970
This is a step towards supporting `statx()`, which allows the set of
fields it returns to be specified by the caller. Currently, the existing
`stat()` and `fstat()` calls continue to be made, and there are no
behavioural changes — but the new wrapper functions will be extended in
future.
Helps: #1970
Correct an off-by-one error in hex_unescape_string()'s computation of
the output string length.
(Turned into a git-format patch by Philip Withnall. Original patch
submitted on the Debian bug tracker, bug#962912.)
