Re: _wstat on Windows (actually stat stuff in general)

[Tor Lillqvist <tml iki fi>]

> "_wstat does not work with Windows Vista symbolic links. In these cases, 
> _wstat will always report a file size of 0. _stat does work correctly with 
> symbolic links."

Ugh, how weird and unexpected. (My expectation would have been that
neither supports symbolic links.) For which C runtime is this, btw,
the system msvcrt.dll, or some of the MSVC-version-specific ones?

Anyway, I think the only sensible thing to do is then to not use
either _wstat() or _stat(). We don't want to miss the full Unicode
support, and I guess this symbolic link stuff is useful, too.

Instead, we should just use the Win32 API to fill in the meaningful
fields of a struct stat. Yeah, following symbolic links manually might
be painful; I have no idea how to do that.

(Of course, when I say "we", I actually mean "you", as I don't really
take much part in GLib/GTK+ development currently... sorry. Just
noticed this thread when browsing the gtk-devel-list archove, and
*had* to follow-up...)

Anyway, isn't g_stat() kinda deprecated? Should it be? Partly exactly
because of this horrible potential for confusion with the several
"struct stat" variants on Windows (and also on some Unixes, I guess,
although there at least there is typically only one C
library). Doesn't GIO's APIs to get file
properties/attributes/whatever they are called supersede g_stat()?

> Here's how I would define the GStatBuf data type:
> 
> typedef struct GStatBuf {
>    guint32          st_dev;
>    guint64          st_ino;
>    guint16          st_mode;
>    guint16          st_nlink;
>    guint32          st_uid;
>    guint32          st_gid;
>    guint32          st_rdev;
>    gint64           st_size;
>    gint32           st_atime;
>    gint32           st_mtime;
>    gint32           st_ctime;
> } GStatBuf;

Er, no. NO.

This definitely is pointless, GIO supersedes g_stat() etc in much
cleaner fashion.

Why on earth would we want to use 32-bit timestamps in a new API? Or
just 16-bit st_nlink?

Why would we want the extremely Unix-specific st_mode to show up in a
portability layer at all? st_mode is on Windows always just a
best-effort (or not even that good an effort) fabrication. Many
POSIXes support ACLs in file systens and such might be common for some
file systems on some POSIX platforms.  Any software supposed to be
generic and good should take that into consideration anyway when
figuring out the protection of some file. A single st_mode field is
basically useless in modern portable APIs.

st_uid and st_gid are also totally Unix-specifc, of course.

> While in gstdio I'd also add the glaring-by-their-omission g_lseek, 
> g_fseek, and g_ftell all of which could take a gint32 as their argument or 
> return value.

That is a glaring omission only if you misunderstand the purpose of
gstdio.h. It is not supposed to be a wrapper for any file I/O related
functions. Its sole purpose (at least when it was created) is to take
care of the *file name* problems. It even says this in a comment:

/* Wrappers for C library functions that take pathname arguments. On
 * Unix, the pathname is a file name as it literally is in the file
 * system. On well-maintained systems with consistent users who know
 * what they are doing and no exchange of files with others this would
 * be a well-defined encoding, preferably UTF-8. On Windows, the
 * pathname is always in UTF-8, even if that is not the on-disk
 * encoding, and not the encoding accepted by the C library or Win32
 * API.
 */

Beafing up gstdio.h now is too late. All newer file system portability
related stuff in GLib is in GIO, surely.

--tml