[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fstat on mingw
From: |
Paul Eggert |
Subject: |
Re: fstat on mingw |
Date: |
Fri, 30 Jun 2006 15:54:54 -0700 |
User-agent: |
Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) |
Eric Blake <address@hidden> writes:
> * functions.texi (Function Portability): Document fstat
> limitation on mingw.
That's only one of the limitations. As I understand it, the
limitations include;
st_atime, st_mtime, and st_ctime may not have 1-second resolution.
st_gid and st_uid are always 0.
st_dev and st_rdev are always equal. It's not clear to me when
they're zero; the Microsoft documentation for _fstat says "If a
device, handle; otherwise 0." whereas for _stat it says "Drive number
of the disk containing the file",
st_ino is "meaningless" (see
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_crt__stat.2c_._wstat.2c_._stati64.2c_._wstati64.asp>).
st_mode's rw bits have some constraints on them (I don't know what),
and its x bits are determined from the file name extension (!).
st_nlink is always 1 on non-NTFS file systems. (Dunno about NTFS.)
Also, you must include <sys/types.h> before <sys/stat.h>.
Also, similar limitations apply to lstat and stat.
Also, I've heard that lstat and stat fail if passed a drive identifier
like "A:".
(There may be some other limitations too, but you're the DOS expert. :-)
This is starting to get complicated. Perhaps we should move the
Microsoft-related stuff into a separate file, and simply
cross-reference to it from the main files. Many GNU developers don't
care much about porting to systems that have these problems.
- fstat on mingw, Eric Blake, 2006/06/30
- Re: fstat on mingw,
Paul Eggert <=