#1009 stat st_mode wrong for file name = "NUL"

[Bruno Haible]

The attached program prints the stat() mode of the file name "NUL".

Result with MSVC 14, mingw 13 "UCRT":

$ ./foo
ret = 0, mode = 0x2000, regular? = 0, character? = 1
fd = 3

Result with mingw 5, 10, 13:

$ ./foo
ret = 0, mode = 0x81b6, regular? = 1, character? = 0
fd = 3

The latter result makes no sense: "NUL" is not a regular file,
it's a character device.

[Pali]

This is a bug in the msvcrt _stat function. mingw-w64 provides stat function which is wrapper around the msvcrt _stat (or UCRT _stat depending on the configuration) and already fixes some msvcrt issues (e.g. allow passing directory name with trailing slash). But this issue one with "NUL" filename is not handled.

On the other hand, msvcrt _fstat function on fd retrieved from open("NUL", O_RDWR) is working correctly.

Seems that this is a problem also directly in the WinAPI FindFirstFile function, which _stat is probably using.

So to fix this mingw-w64 stat function bug (not the msvcrt _stat function), it would be needed to implement mingw-w64 stat as wrapper around msvcrt _fstat function. But for that case the msvcrt _open cannot be used as it cannot open directory. Instead of _open it would be needed combination of WinAPI CreateFileA with FILE_FLAG_BACKUP_SEMANTICS flag (which is for allowing to open handle to directory) and msvcrt _open_osfhandlefunction which get CRT fd from WinAPI HANDLE.

[Pali]

I implement the fix as described above and sent it to the list:
https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/20260224201812.4f7jrjgbbx5ovjwm%40pali/

With the change, the mingw-w64 stat() function for NUL path when build against msvcrt.dll will properly return character? = 1 via S_ISCHR().

[LIU Hao]

This has been fixed in 6d91c946651a384d19b7d8fc69ba8d3df3ab3e4b.