[PATCH v5 0/1] MR6790: ntdll: use __wine_unix_spawnvp() to invoke unmount command.

[Michael Lelli (＠toadking)]

Fix umounting filesystems mounted on paths with spaces.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57391

--
  v5: ntdll: use __wine_unix_spawnvp() to invoke unmount command.

https://gitlab.winehq.org/wine/wine/-/merge_requests/6790

[PATCH v5 1/1] ntdll: use __wine_unix_spawnvp() to invoke unmount command.

[Michael Lelli]

From: Michael Lelli

Fix umounting filesystems mounted on paths with spaces.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57391
---
 dlls/ntdll/unix/file.c | 26 ++++++++++++++------------
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/dlls/ntdll/unix/file.c b/dlls/ntdll/unix/file.c
index 44adc4f4626..e1d3e3979b5 100644
--- a/dlls/ntdll/unix/file.c
+++ b/dlls/ntdll/unix/file.c
@@ -3975,23 +3975,25 @@ static NTSTATUS unmount_device( HANDLE handle )
         {
             if ((mount_point = get_device_mount_point( st.st_rdev )))
             {
+                LARGE_INTEGER time;
 #ifdef __APPLE__
-                static const char umount[] = "diskutil unmount >/dev/null 2>&1 ";
+                static char diskutil[] = "diskutil";
+                static char unmount[] = "unmount";
+                char *argv[4] = {diskutil, unmount, mount_point, NULL};
 #else
-                static const char umount[] = "umount >/dev/null 2>&1 ";
+                static char umount[] = "umount";
+                char *argv[3] = {umount, mount_point, NULL};
 #endif
-                char *cmd;
-                if (asprintf( &cmd, "%s%s", umount, mount_point ) != -1)
-                {
-                    system( cmd );
-                    free( cmd );
+                __wine_unix_spawnvp( argv, TRUE );
 #ifdef linux
-                    /* umount will fail to release the loop device since we still have
-                       a handle to it, so we release it here */
-                    if (major(st.st_rdev) == LOOP_MAJOR) ioctl( unix_fd, 0x4c01 /*LOOP_CLR_FD*/, 0 );
+                /* umount will fail to release the loop device since we still have
+                    a handle to it, so we release it here */
+                if (major(st.st_rdev) == LOOP_MAJOR) ioctl( unix_fd, 0x4c01 /*LOOP_CLR_FD*/, 0 );
 #endif
-                }
-                free( mount_point );
+                /* Add in a small delay. Without this subsequent tasks
+                    like IOCTL_STORAGE_EJECT_MEDIA might fail. */
+                time.QuadPart = -100 * (ULONGLONG)10000;
+                NtDelayExecution( FALSE, &time );
             }
         }
         if (needs_close) close( unix_fd );

[PATCH v5 1/1] ntdll: use __wine_unix_spawnvp() to invoke unmount command.

[Marvin]

Hi,

It looks like your patch introduced the new failures shown below.
Please investigate and fix them before resubmitting your patch.
If they are not new, fixing them anyway would help a lot. Otherwise
please ask for the known failures list to be updated.

The tests also ran into some preexisting test failures. If you know how
to fix them that would be helpful. See the TestBot job for the details:

The full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=149539

Your paranoid android.

=== debian11b (64 bit WoW report) ===

user32:
input.c:4305: Test succeeded inside todo block: button_down_hwnd_todo 1: got MSG_TEST_WIN hwnd 00000000017100EA, msg WM_LBUTTONDOWN, wparam 0x1, lparam 0x320032

[Michael Lelli (＠toadking)]

During some more testing I noticed the `eject` program was failing to eject the disc sometimes and I think it comes down to all the device resources not being removed yet. (The CDROMEJECT ioctl was returning EBUSY.) Adding in a small delay fixes it for me (was able to run eject 10 times with no failure when before it would fail like one every three times). As for why it wasn't happening before, I can only assume that the extra overhead from the shell system() makes was accounting enough for it. The util-linux eject program doesn't actually open the block device until it does the unmounting (also by calling umount) so the extra overhead from opening the device might add enough delay there as well.

I'm not super happy with this fix but as FSCTL_DISMOUNT_VOLUME normally takes a couple seconds anyway it probably won't cause any serious performance issues.