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
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
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).
This is meant for opaque, non-POSIX-like backends to indicate that the
URI is not persistent. Applications should look at
G_FILE_ATTRIBUTE_STANDARD_SYMLINK_TARGET for the persistent URI.
Examples of such backends could be a portal for letting sandboxed
applications access the file-system, or a database-backed storage like
Google Drive.
In these cases, the user visible file and folder names are different
from the real identifiers, used by the backend. So, a request to
create google-drive://user@gmail.com/foo/New\ File, would actually
lead to google-drive://user@gmail.com/foo/bar on the server even though
the user visible name is still "New File". Since the server-defined URI
is persistent and sanity-checked by the backend, it is recommended that
applications switch to it as soon as possible. Backends will try to
keep a mapping from "fake" to "real" URIs, but those are only on a
best effort basis. They might not be persistent or have the same
guarantees as the "real" URIs.
https://bugzilla.gnome.org/show_bug.cgi?id=741602
This indicates whether the thumbnail (given by G_FILE_ATTRIBUTE_THUMBNAIL_PATH)
is valid — i.e. to represent the file in its current state. If
G_FILE_ATTRIBUTE_THUMBNAIL_IS_VALID is FALSE (for a normal _or_ failed
thumbnail) it means the file has changed since the thumbnail was generated, and
the thumbnail is out of date.
Part of checking thumbnail validity (by the spec) involves parsing
headers out of the thumbnail .png so we include some (small) code to do
that in a separate file. We will likely want to copy this code to gvfs
to do the same for GVfsFile.
Heavily based on a patch from Philip Withnall <philip.withnall@collabora.co.uk>
who suggested the feature and designed the API.
https://bugzilla.gnome.org/show_bug.cgi?id=709898
This patch and the previous ones fixes the performance issues noted in
Bug 587089 – lookup_attribute() takes too much CPU
It increases performance for querying attributes by ~15% in my tests.
