Bug 13403 introduced support for the non-POSIX variants of these APIs
found on a system called "DG/UX".  Meanwhile, the complicated checks
here are breaking cross-builds on systems that we actually care about.

Remove the complicated checks and replace them with AC_CHECK_FUNCS.
Remove the resulting dead code from a couple of .c files.

https://bugzilla.gnome.org/show_bug.cgi?id=756475

Previously, GLib returned text/plain for empty files.

This is important because people may want to open empty (eg:
just-created) text files with the text editor.

An unintended side-effect of b6fc1df0
caused GLib to start returning application/octet-stream instead of
text/plain for these files.

This commit is essentially a revert of that commit, with a different
solution: we move the special-case up a bit in the function and
hard-code it to text/plain.

This change does not exactly maintain the old behaviour: previously, a
"fast" lookup would have returned application/octet-stream on an empty
file and now it will return text/plain.  I consider this to be an
improvement (since we're returning better data) and don't expect it to
cause problems.

https://bugzilla.gnome.org/show_bug.cgi?id=755795

This will prevent attempting to read from some files that appear normal but are
really device-like, such as those in /proc and /sys.

If we can't stat() the file then don't bother attempting to sniff, either.

https://bugzilla.gnome.org/show_bug.cgi?id=708525

FreeBSD and NetBSD have field st_birthtim and st_birthtime in struct stat,
respectively, which can be used to get file creation time on supported file
systems such as UFS2 and tmpfs.

https://bugzilla.gnome.org/show_bug.cgi?id=749492

https://bugzilla.gnome.org/show_bug.cgi?id=734946

Just ignore the return value, since we're checking contents != NULL.

https://bugzilla.gnome.org/show_bug.cgi?id=733576

'folder' is the name of the folder icon in the incon naming spec,
and the Adwaita icon theme doesn't include an inode-directory icon.
This fixes folders appearing as generic file in the file chooser.

https://bugzilla.gnome.org/show_bug.cgi?id=731996

As of e6af432b, g_content_type_get_symbolic_icon() returns non-symbolic
fallbacks. Thus, we can't append another symbolic icon to the fallbacks.

The special case was a bit of a hack anyway. It was only applied to
themed icons and there was no generic fallback for mime types that are
not folders.

https://bugzilla.gnome.org/show_bug.cgi?id=726046

glocalfileinfo.c: In function '_g_local_file_info_get':
glocalfileinfo.c:1955:11: warning: passing argument 3 of
'get_thumbnail_attributes' from incompatible pointer type [enabled by
default]
           get_thumbnail_attributes (path, info, &statbuf);
           ^
glocalfileinfo.c:1285:1: note: expected 'const struct GStatBuf *' but
argument is of type 'struct _stati64 *'
 get_thumbnail_attributes (const char     *path,

https://bugzilla.gnome.org/show_bug.cgi?id=711547

g_strconcat() allocates memory, it needs to be freed.

==10653== 1,400 bytes in 50 blocks are definitely lost in loss record
1,838 of 1,851
==10653==    at 0x4A0645D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10653==    by 0x54ACB22: g_malloc (gmem.c:102)
==10653==    by 0x54ACE4D: g_malloc_n (gmem.c:343)
==10653==    by 0x54C8463: g_strconcat (gstrfuncs.c:589)
==10653==    by 0x4D6ED38: get_xattrs_from_fd (glocalfileinfo.c:660)
==10653==    by 0x4D71622:
_g_local_file_info_get_from_fd (glocalfileinfo.c:2028)
==10653==    by 0x4D731A0:
g_local_file_input_stream_query_info (glocalfileinputstream.c:356)
==10653==    by 0x4C996D8:
g_file_input_stream_query_info (gfileinputstream.c:148)
==10653==    by 0x4C863F6: file_copy_fallback (gfile.c:3120)
==10653==    by 0x4C86DD2: g_file_copy (gfile.c:3398)

https://bugzilla.gnome.org/show_bug.cgi?id=722357

In Windows development environments that have it, <unistd.h> is mostly
just a wrapper around several other native headers (in particular,
<io.h>, which contains read(), close(), etc, and <process.h>, which
contains getpid()). But given that some Windows dev environments don't
have <unistd.h>, everything that uses those functions on Windows
already needed to include the correct Windows header as well, and so
there is never any point to including <unistd.h> on Windows.

Also, remove some <unistd.h> includes (and a few others) that were
unnecessary even on unix.

https://bugzilla.gnome.org/show_bug.cgi?id=710519

Assume unix platforms support the original POSIX.1 standard.
Specifically, assume that if G_OS_UNIX, then we have chown(),
getcwd(), getgrgid(), getpwuid(), link(), <grp.h>, <pwd.h>,
<sys/types.h>, <sys/uio.h>, <sys/wait.h>, and <unistd.h>.

Additionally, since all versions of Windows that we care about also
have <sys/types.h>, we can remove HAVE_SYS_TYPES_H checks everywhere.

Also remove one include of <sys/times.h>, and the corresponding
configure check, since the include is not currently needed (and may
always have just been a typo for <sys/time.h>).

https://bugzilla.gnome.org/show_bug.cgi?id=710519

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

https://bugzilla.gnome.org/show_bug.cgi?id=689223

We were using PATH_MAX to size a static array for reading lines from
the .hidden file.  Some platforms (Hurd) don't declare a PATH_MAX.

Switch to using g_file_get_contents() and g_str_split('\n') instead.

Also take the time to clean up a bit with a switch to using a 'set mode'
GHashTable (since this code was originally written before we had those).

This patch is largely based on a patch from Emilio Pozuelo Monfort (who
also reported the bug).

https://bugzilla.gnome.org/show_bug.cgi?id=695147

There are two benefits to this:

1) We can centralize any operating system specific knowledge of
   close-vs-EINTR handling.  For example, while on Linux we should never
   retry, if someone cared enough later about HP-UX, they could come by
   and change this one spot.
2) For places that do care about the return value and want to provide
   the caller with a GError, this function makes it convenient to do so.

Note that gspawn.c had an incorrect EINTR loop-retry around close().

https://bugzilla.gnome.org/show_bug.cgi?id=682819

For OSTree, I use Gio and also really care about performance.  It's
disturbing to see open('.hidden') all over my straces and such.  At
the moment I have an explicit set of things to query, as opposed to
"standard::*", since even before this that also implies an lstat() of
the parent directory.

This matches up with what we do for all the other attributes.

See https://bugzilla.gnome.org/show_bug.cgi?id=587806
https://bugzilla.gnome.org/show_bug.cgi?id=691558

This was reported in bug 689800.

https://bugzilla.gnome.org/show_bug.cgi?id=689800Signed-off-by: David Zeuthen <zeuthen@gmail.com>

https://bugzilla.gnome.org/show_bug.cgi?id=587806

... and g_content_type_get_generic_icon_name(). The new functions are
implemented for Win32 since commit dace477c, so we no longer need to
guard them with G_OS_UNIX.

This reverts commit cb0ed84d.

It wasn't meant to be pushed yet.

Fixes: https://bugzilla.gnome.org/686895

When building the file attribute table info for local files, use
thumbnail paths in $XDG_CACHE_DIR/thumbnails/large in addition to
$XDG_CACHE_DIR/thumbnails/normal.

Failing to do this would cause an application that creates large
thumbnails by default to never find any value for
G_FILE_ATTRIBUTE_THUMBNAIL_PATH, with no
G_FILE_ATTRIBUTE_THUMBNAILING_FAILED set, which might cause the
application to either think thumbnailing is still in progress, or
blindly requeue thumbnail operations in a loop.

Large thumbnails are generally preferred, so we now default to the path
of a large thumbnail (in case both are present).

https://bugzilla.gnome.org/show_bug.cgi?id=686895

The newly-introduced functions, g_content_type_get_symbolic_icon() and
g_content_type_get_generic_icon_name() don't seem to be for Windows, at
least for now.  So filter them out from gio.symbols on Windows.

Also, glocalfileinfo.c calls g_content_type_get_symbolic_icon() in
get_icon(), so only build that code when on Unix, for the time being.

https://bugzilla.gnome.org/show_bug.cgi?id=684278

https://bugzilla.gnome.org/show_bug.cgi?id=682101

https://bugzilla.gnome.org/show_bug.cgi?id=682101

Because it now handles EINTR.  And we should do so.  While most people
use Linux, which tries very hard to avoid propagating EINTR back up
into userspace, it can still happen.

https://bugzilla.gnome.org/show_bug.cgi?id=682833

https://bugzilla.gnome.org/show_bug.cgi?id=675168

This will be used in the next commit.

Typo fix and changing "is not recommended" to the nice version of "don't
do this", aka "causes undefined behavior".

Non-technical users won't know that "stating" refers to stat(2), so we
just use "error when getting information" now.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>

_GNU_SOURCE must be defined before including any other (system)
header, so defining it in glib-unix.h (and hoping no one has included
anything else before that) is wrong. And the "#define _USE_GNU"
workaround for this problem in gnetworkingprivate.h is even wronger
(and still prone to failure anyway due to single-include guards).

Fix this by defining _GNU_SOURCE in config.h when building against
glibc. In theory this is bad because new releases of glibc may include
symbols that conflict with glib symbols, which could then cause
compile failures. However, most people only see new releases of glibc
when they upgrade their distro, at which point they also generally get
new releases of gcc, which have new warnings/errors to clean up
anyway.

https://bugzilla.gnome.org/show_bug.cgi?id=649201

From GCC 4.6.

Following the behaviour of ls here, we should return at least the
file name, if we can't get any other information about a file. To
do this, handle EACCESS on stat() calls.

Patch by Tomas Bzatek, see bug 623692

Define GStatBuf as the type used by g_stat() and g_lstat(). Replaces
the non-public struct tag _g_stat_struct. Mostly relevant for Windows
where there are several variants of stat-style structs. On POSIX, is
just another name for struct stat.

Actually, also on many POSIX systems there are in fact several
variants of struct stat and corresponding stat() and lstat()
functions, but as g_stat and g_lstat are normally on POSIX just macros
that expand to stat and lstat, this should not cause a problem. It's
only when it's the actual g_stat() or g_lstat() implementation inside
GLib that gets called that one needs to be sure the passed struct is
the same as what GLib expects.)