tree 9540fbf4b2c1858817281e543fb093d97d13079d
parent 6263a2fced11f5834975c9af5001adc9161bf5bf
author Pali Rohár <pali.rohar@gmail.com> 1765659767 +0100
committer LIU Hao <lh_mouse@126.com> 1775469081 +0800
gpgsig -----BEGIN SSH SIGNATURE-----
 U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgpNkDDBuVPiz0dPd+zGoqB2ET19
 YkAU0wAtjm07QRvk4AAAADZ2l0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5
 AAAAQGal+3CrzDr4T+DfiF7O/7XN8Vr1GYkWzTkMC5XBcexGu5gzMN1bai97VJO5/uPwF4
 HagQcHhLJEGX8Rr5P0FAk=
 -----END SSH SIGNATURE-----

crt: Fix mingw-w64 stat implementation

MS CRT _stat() implementation is known to be broken in different cases.
mingw-w64 already contains fixup code for path processing, but this is not
enough. For example _stat() returns incorrect type for Windows devices
(like NUL) and rejects \\?\ paths with ENOENT error. This is probably because
WinAPI FindFirstFile function (which is in lot of times used as replacement
for POSIX stat) does not return file type at all.

mingw-w64 already provides working fstat() implementation (as wrapper
around MS CRT _fstat()) which can be used as stat() fallback for already
opened file handle.

So if the MS CRT _stat() fails or returns that file type is regular file
then try to open path in read-only mode and call mingw-w64 fstat() on it.

Note that opening path can fail for many reasons (for example denied by
ACL, denied by shared reservation or denied by delete_pending state) while
regular FindFirstFile is working fine. So do not take errors from opening
path as fatal error. Use the fstat just for correcting information returned
by MS CRT _stat() function.

Bug: https://sourceforge.net/p/mingw-w64/bugs/1009/
Bug: https://github.com/mingw-w64/mingw-w64/issues/139
Co-authored-by: LIU Hao <lh_mouse@126.com>
Signed-off-by: LIU Hao <lh_mouse@126.com>