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