>> 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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list