[PATCH 0/1] MR1425: ntdll: Return FILE_DEVICE_DISK for Unix FIFOs and sockets from get_device_info().

[Paul Gofman (＠gofman)]

Currently GetFileType() ends up returning the file type solely based on Unix fd type if it gets it from server. The problematic case is when our process gets a pipe or socket fd as a stdin or stderr from Unix. The server object which gets created through wine_server_fd_to_handle is a regular file regardless of the underlying Unix fd type. It probably can't be anything else, at least for pipes, as the pipe should have both ends but we have only one in this case.

That causes problems, e. g., with libuv (used, e. g., by Vampire Survivors). It checks stdout handle type and if it is pipe it tries to do SetNamedPipeHandleState() on it and does not tolerate the failure.

It looks more sensible to me to report all the pipes and sockets created through wine_server_fd_to_handle() as regular files as that matches the server objects we have for them. When that is not the case we should get the correct type from server fd type.

[PATCH 1/1] ntdll: Return FILE_DEVICE_DISK for Unix FIFOs and sockets from get_device_info().

[Paul Gofman]

From: Paul Gofman

---
 dlls/ntdll/unix/file.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/dlls/ntdll/unix/file.c b/dlls/ntdll/unix/file.c
index e80eb368e8a..58c7044fbae 100644
--- a/dlls/ntdll/unix/file.c
+++ b/dlls/ntdll/unix/file.c
@@ -6550,7 +6550,7 @@ NTSTATUS get_device_info( int fd, FILE_FS_DEVICE_INFORMATION *info )
     }
     else if (S_ISFIFO( st.st_mode ) || S_ISSOCK( st.st_mode ))
     {
-        info->DeviceType = FILE_DEVICE_NAMED_PIPE;
+        info->DeviceType = FILE_DEVICE_DISK;
     }
     else if (is_device_placeholder( fd ))
     {
@@ -6659,10 +6659,11 @@ NTSTATUS WINAPI NtQueryVolumeInformationFile( HANDLE handle, IO_STATUS_BLOCK *io
                                               void *buffer, ULONG length,
                                               FS_INFORMATION_CLASS info_class )
 {
+    enum server_fd_type fd_type;
     int fd, needs_close;
     NTSTATUS status;

-    status = server_get_unix_fd( handle, 0, &fd, &needs_close, NULL, NULL );
+    status = server_get_unix_fd( handle, 0, &fd, &needs_close, &fd_type, NULL );
     if (status == STATUS_BAD_DEVICE_TYPE)
     {
         struct async_irp *async;
@@ -6729,7 +6730,15 @@ NTSTATUS WINAPI NtQueryVolumeInformationFile( HANDLE handle, IO_STATUS_BLOCK *io
         {
             FILE_FS_DEVICE_INFORMATION *info = buffer;

-            if ((status = get_device_info( fd, info )) == STATUS_SUCCESS)
+            if (fd_type == FD_TYPE_SOCKET || fd_type == FD_TYPE_PIPE)
+            {
+                info->Characteristics = 0;
+                info->DeviceType = FILE_DEVICE_NAMED_PIPE;
+                status = STATUS_SUCCESS;
+            }
+            else status = get_device_info( fd, info );
+
+            if (!status)
                 io->Information = sizeof(*info);
         }
         break;

[Alexandre Julliard (＠julliard)]

> That causes problems, e. g., with libuv (used, e. g., by Vampire Survivors). It checks stdout handle type and if it is pipe it tries to do SetNamedPipeHandleState() on it and does not tolerate the failure.
>
> It looks more sensible to me to report all the pipes and sockets created through wine_server_fd_to_handle() as regular files as that matches the server objects we have for them. When that is not the case we should get the correct type from server fd type.

I'm not sure that reporting a regular file is a good idea. Next we'll find an app that assumes that it supports SetFilePointer() and the like...

[Paul Gofman]

On 11/18/22 01:11, Alexandre Julliard (@julliard) wrote:
> > That causes problems, e. g., with libuv (used, e. g., by Vampire Survivors). It checks stdout handle type and if it is pipe it tries to do SetNamedPipeHandleState() on it and does not tolerate the failure.
> >
> > It looks more sensible to me to report all the pipes and sockets created through wine_server_fd_to_handle() as regular files as that matches the server objects we have for them. When that is not the case we should get the correct type from server fd type.
>
> I'm not sure that reporting a regular file is a good idea. Next we'll find an app that assumes that it supports SetFilePointer() and the like...

Maybe we can call it FILE_DEVICE_UNKNOWN? I guess it reflects the state 
of things best, we will get FILE_TYPE_CHAR in GetFileType() and the fd 
flagged as TTY in msvcrt.

[PATCH 0/1] MR1425: ntdll: Return FILE_DEVICE_DISK for Unix FIFOs and sockets from get_device_info(). - closed

[Paul Gofman (＠gofman)]

This merge request was closed by Paul Gofman.