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

[Tor Lillqvist <tml iki fi>]

>> 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?
>
> The MSDN documentation doesn't specify. I suspect its all of them TBH.

Actually, looking in the C library sources that come with MSVC2008, I
see no sign of such a difference in _stat() vs. _wstat().

Both in stat.c and stat64.c (these are the files that contain the
actual implementation of both the "ANSI" and wide-char versions of the
stat family of functions) I see code that checks
(findbuf.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT) &&
(findbuf.dwReserved0 == IO_REPARSE_TAG_SYMLINK) . But on the other
hand, as far as I can see, this code is used to make stat() (etc) work
as lstat(), not to actually follow the symlink! (But just if the
symlink is the last component of the path; I assume symlinks in the
middle of the pathname are followed transparently by the
FindFirstFile().

So I wonder which is correct, the documentation, or what the code
seems to imply. Experimentation would be useful...

Of course, it might be that it is actually FindFirstFileA() vs.
FindFirstFileW() that exhibits some difference.

> Sure but if all I want to know how big a file is, do I *really* want to link
> in all of that extra crud? GIO is huge. There are times when the low level
> functions are just plain appropriate.

I would say, bah. Any actively maintained (or recently written)
GLib-using code that doesn't use GIO by now is just being maintained
or written in a misguided fashion.

> People really do want to use stat rather than GIO. I do, and I've had
> private emails from others who do too.

Well, then you just will have to live with the various breakages;) I
don't think you will be able to convince people it would be a good
idea to add more bells and whistles in the form of stat() -style APIs
when GLib already has a much cleaner and ABI/API
stability/extendability safe (and other nice words) way to get
information about files.

--tml