Non-file file descriptors may be mishandled in ntpath

[zooba]

A couple of bugs slipped by when the new accelerator functions were added.

• If _Py_get_osfhandle_noraise() fails (e.g. a bad file descriptor), the result is INVALID_HANDLE_VALUE, but the thread's last error isn't set and is thus a random error code. It could be one of the errors that's handled by calling STAT(), but in this case there is no _path.wide value to check. It happens that CreateFileW() doesn't raise an OS exception that crashes the process when passed a null pointer for lpFileName, but that's not documented and shouldn't be relied on.
• If GetFileType(hfile) isn't FILE_TYPE_DISK, we have to return a false result. Since we didn't open the file, we don't know whether or not it has a pending synchronous operation that's blocked indefinitely. For example, a pipe or character file could have a pending synchronous read that may never complete. In this case, GetFileInformationByHandleEx() would block.

Originally posted by @eryksun in #103485 (comment)

This applies to the specialised isfile/isdir/islink/exists functions in ntpath when passed a file number.

[eryksun]

Also, a pipe file shouldn't be identified as a regular file, whether the test is by file descriptor or by name. Thus when checking isfile(), GetFileType(hfile) has to be checked regardless of whether we opened the file. A regular file must be a FILE_TYPE_DISK file, and its FileAttributes must be non-zero (e.g. FILE_ATTRIBUTE_NORMAL must be set if no other attributes are set).

---

On a related note, os.Direntry.is_file() is also wrong for pipe files in case of os.scandir('//./pipe/') or os.scandir('//?/pipe/'). Unfortunately all we have are the file attributes in this case, which don't help us because the named-pipe filesystem properly returns FILE_ATTRIBUTE_NORMAL. However, it's unlikely that anyone would call os.scandir() on "//./pipe/" and care about the result of is_file().