[PATCH] msvcrt:msvcrt_get_flags: Fix bug 51846 - fopen(..., "wx")

[Ted Lyngmo]

This fixes bug 51846: Standard library call fopen(..., "wx") not
recognized - causes destruction of data.

Signed-off-by: Ted Lyngmo <ted(a)lyncon.se>
---
 dlls/msvcrt/file.c       |  3 +++
 dlls/msvcrt/tests/file.c | 27 +++++++++++++++++++++++++++
 2 files changed, 30 insertions(+)

diff --git a/dlls/msvcrt/file.c b/dlls/msvcrt/file.c
index b0eeaf2a351..355638fa783 100644
--- a/dlls/msvcrt/file.c
+++ b/dlls/msvcrt/file.c
@@ -1586,6 +1586,9 @@ static int msvcrt_get_flags(const wchar_t* mode, int *open_flags, int* stream_fl
       *open_flags |=  _O_TEXT;
       *open_flags &= ~_O_BINARY;
       break;
+    case 'x':
+      *open_flags |= _O_EXCL;
+      break;
     case 'D':
       *open_flags |= _O_TEMPORARY;
       break;
diff --git a/dlls/msvcrt/tests/file.c b/dlls/msvcrt/tests/file.c
index 1d74c6135b8..3b96be58126 100644
--- a/dlls/msvcrt/tests/file.c
+++ b/dlls/msvcrt/tests/file.c
@@ -110,6 +110,32 @@ static void test_filbuf( void )
     unlink("filbuf.tst");
 }
 
+static void test_fopen_exclusive( void )
+{
+    static const char * const testfile = "fileexcl.tst";
+    FILE *fp;
+
+    fp = fopen(testfile, "wx");
+    ok(fp != NULL, "creating file with mode wx failed\n");
+    if(fp) fclose(fp);
+
+    fp = fopen(testfile, "wx");
+    ok(fp == NULL, "overwrote existing file with mode wx\n");
+    if(fp) fclose(fp);
+
+    unlink(testfile);
+
+    fp = fopen(testfile, "w+x");
+    ok(fp != NULL, "creating file with mode w+x failed\n");
+    if(fp) fclose(fp);
+
+    fp = fopen(testfile, "w+x");
+    ok(fp == NULL, "overwrote existing file with mode w+x\n");
+    if(fp) fclose(fp);
+
+    unlink(testfile);
+}
+
 static void test_fdopen( void )
 {
     static const char buffer[] = {0,1,2,3,4,5,6,7,8,9};
@@ -2841,6 +2867,7 @@ START_TEST(file)
 
     /* testing stream I/O */
     test_filbuf();
+    test_fopen_exclusive();
     test_fdopen();
     test_fopen_fclose_fcloseall();
     test_fopen_s();
-- 
2.31.1

[Ted Lyngmo]

I noticed that the tests I added for this patch failed to pass TestBot. 
This is my first patch so I may have missed something.

I ran the test suite locally like this:

WINETEST_DEBUG=1 ./wine ./dlls/msvcrt/tests/msvcrt_test.exe file

When running the test suite with the Wine version that is included in 
Fedora 34, it fails as expected:

file.c:123: Test failed: overwrote existing file with mode wx
file.c:133: Test failed: overwrote existing file with mode w+x

With my patch, my test cases passes locally but TestBot says:

file.c:119: Test failed: creating file with mode wx failed
file.c:129: Test failed: creating file with mode w+x failed

Any advice?

Best regards,
Ted Lyngmo

Den 2021-10-07 kl. 18:52, skrev Ted Lyngmo:
> This fixes bug 51846: Standard library call fopen(..., "wx") not
> recognized - causes destruction of data.

[Piotr Caban]

Hi Ted,

On 10/7/21 7:48 PM, Ted Lyngmo wrote:
> I noticed that the tests I added for this patch failed to pass TestBot. 
> This is my first patch so I may have missed something.
>
> I ran the test suite locally like this:
>
> WINETEST_DEBUG=1 ./wine ./dlls/msvcrt/tests/msvcrt_test.exe file
>
> When running the test suite with the Wine version that is included in 
> Fedora 34, it fails as expected:
>
> file.c:123: Test failed: overwrote existing file with mode wx
> file.c:133: Test failed: overwrote existing file with mode w+x
>
> With my patch, my test cases passes locally but TestBot says:
>
> file.c:119: Test failed: creating file with mode wx failed
> file.c:129: Test failed: creating file with mode w+x failed
>
> Any advice?
> The tests are failing on Windows. I've tried running them on fully 
> updated Windows 10 and it also fails there. Is the 'x' format only 
> supported in ucrtbase.dll (you have added the tests for msvcrt.dll)?

Thanks,
Piotr

[Ted Lyngmo]

Hi Piotr and, wow, that's a quick reply
> > With my patch, my test cases passes locally but TestBot says: >> 
> > file.c:119: Test failed: creating file with mode wx failed>>
> > file.c:129: Test failed: creating file with mode w+x failed >> The tests 
> > are failing on Windows.
> > Yeah, I tried that too now and indeed it fails there.
> I've tried running them on fully updated Windows 10 and it also fails 
> there. Is the 'x' format only supported in ucrtbase.dll (you have added 
> the tests for msvcrt.dll)?

The change I've made to support the fopen() "x" mode is in 
"dlls/msvcrt/file.c"

It's supposed to extend all functions that uses msvcrt_get_flags() to 
support the "x" mode when opening files.

That's the only place where I could find "msvcrt_get_flags" which I 
searched for when running a program, that I had compiled with VS2019, in 
Wine. It printed:

0110:err:msvcrt:msvcrt_get_flags incorrect mode flag: x

.. and successfully overwrote the existing file. Really dangerous. When 
running that program in native WIndows, it does the right thing. The 
same VS2019-program also works as it should in Wine, with my patch.

I looked in "dlls/ucrtbase" - but there I could only find printf.c so I 
don't think it should be connected to this?

Tricky... / Ted

[Piotr Caban]

On 10/7/21 8:22 PM, Ted Lyngmo wrote:
> Hi Piotr and, wow, that's a quick reply
> > > With my patch, my test cases passes locally but TestBot says: >> 
> > > file.c:119: Test failed: creating file with mode wx failed>>
> > > file.c:129: Test failed: creating file with mode w+x failed >> The tests 
> > > are failing on Windows.
> > > Yeah, I tried that too now and indeed it fails there.
> > I've tried running them on fully updated Windows 10 and it also fails 
> > there. Is the 'x' format only supported in ucrtbase.dll (you have added 
> > the tests for msvcrt.dll)?
>
> The change I've made to support the fopen() "x" mode is in 
> "dlls/msvcrt/file.c"
>
> It's supposed to extend all functions that uses msvcrt_get_flags() to 
> support the "x" mode when opening files.
>
> That's the only place where I could find "msvcrt_get_flags" which I 
> searched for when running a program, that I had compiled with VS2019, in 
> Wine. It printed:
>
> 0110:err:msvcrt:msvcrt_get_flags incorrect mode flag: x
>
> .. and successfully overwrote the existing file. Really dangerous. When 
> running that program in native WIndows, it does the right thing. The 
> same VS2019-program also works as it should in Wine, with my patch.
>
> I looked in "dlls/ucrtbase" - but there I could only find printf.c so I 
> don't think it should be connected to this?
> The msvcrt and ucrtbase dlls are sharing source. You can introduce 
> version specific behavior by guarding the code in dlls/msvcrt with #if 
> _MSVCR_VER>=140. In order to test the changes with ucrtbase.dll the 
> tests needs to go into dlls/ucrtbase/tests.

[Ted Lyngmo]

2021-10-07 kl. 20:49, Piotr Caban wrote:
> The msvcrt and ucrtbase dlls are sharing source. You can introduce
> version specific behavior by guarding the code in dlls/msvcrt with
> #if _MSVCR_VER>=140.

Oh, ok, so something like this would make it available for the correct 
Windows version?

      case 't':
        *open_flags |=  _O_TEXT;
        *open_flags &= ~_O_BINARY;
        break;
+ #if _MSVCR_VER>=140
+    case 'x':
+      *open_flags |= _O_EXCL;
+      break;
+ #endif
      case 'D':
        *open_flags |= _O_TEMPORARY;
        break;
> In order to test the changes with ucrtbase.dll the tests needs to
> go into dlls/ucrtbase/tests.

Ok, so should I move or copy this test case into 
"dlls/ucrtbase/tests/printf.c" (which is the only test suite using fopen 
in ucrtbase)?

static void test_fopen_exclusive( void )
{
     static const char * const testfile = "fileexcl.tst";
     FILE *fp;

     fp = fopen(testfile, "wx");
     ok(fp != NULL, "creating file with mode wx failed\n");
     if(fp) fclose(fp);

     fp = fopen(testfile, "wx");
     ok(fp == NULL, "overwrote existing file with mode wx\n");
     if(fp) fclose(fp);

     unlink(testfile);

     fp = fopen(testfile, "w+x");
     ok(fp != NULL, "creating file with mode w+x failed\n");
     if(fp) fclose(fp);

     fp = fopen(testfile, "w+x");
     ok(fp == NULL, "overwrote existing file with mode w+x\n");
     if(fp) fclose(fp);

     unlink(testfile);
}

Should I guard that test case with #if _MSVCR_VER>=140 too?

Br,
Ted

[Piotr Caban]

On 10/7/21 9:21 PM, Ted Lyngmo wrote:
> Oh, ok, so something like this would make it available for the correct 
> Windows version?
>
>      case 't':
>         *open_flags |=  _O_TEXT;
>         *open_flags &= ~_O_BINARY;
>         break;
> + #if _MSVCR_VER>=140
> +    case 'x':
> +      *open_flags |= _O_EXCL;
> +      break;
> + #endif
>       case 'D':
>         *open_flags |= _O_TEMPORARY;
>         break;
> Yes, this will add support for 'x' mode only to ucrtbase.
> > In order to test the changes with ucrtbase.dll the tests needs to
> > go into dlls/ucrtbase/tests.
>
> Ok, so should I move or copy this test case into 
> "dlls/ucrtbase/tests/printf.c" (which is the only test suite using fopen 
> in ucrtbase)?
> dlls/ucrtbase/tests/misc.c looks like a better place for the test.
> static void test_fopen_exclusive( void )
> {
>      static const char * const testfile = "fileexcl.tst";
>      FILE *fp;
>
>     fp = fopen(testfile, "wx");
>      ok(fp != NULL, "creating file with mode wx failed\n");
>      if(fp) fclose(fp);
> There's no need for if(fp) check. You can just call fclose.
>
>     fp = fopen(testfile, "wx");
>      ok(fp == NULL, "overwrote existing file with mode wx\n");
>      if(fp) fclose(fp);
> There's no need to close fp (you have just tested that it's NULL).
> Should I guard that test case with #if _MSVCR_VER>=140 too?
> No.

Please also change the commit message to something like:
ucrtbase: Add support for x mode in fopen.

Thanks,
Piotr

[Ted Lyngmo]

Den 2021-10-07 kl. 21:29, skrev Piotr Caban:
> ...
> Please also change the commit message to something like:
> ucrtbase: Add support for x mode in fopen.

Ok, I've now made the changes you suggested. Many thanks for all the 
quick help!

Br,
Ted

[Ted Lyngmo]

... but now something else failed.

misc.c:550: Test failed: 9 should be blank

I can't figure out how I broke "test_isblank" with my patch. That test 
looks unrelated to anything that has to do with fopen(). Perhaps it 
becomes obvious after some sleep :-)

Br,
Ted

Den 2021-10-07 kl. 21:42, skrev Ted Lyngmo:
> Den 2021-10-07 kl. 21:29, skrev Piotr Caban:
> > ...
> > Please also change the commit message to something like:
> > ucrtbase: Add support for x mode in fopen.
>
> Ok, I've now made the changes you suggested. Many thanks for all the 
> quick help!
>
> Br,
> Ted

[Ted Lyngmo]

Also, with the new change, Wine is back to its old/current behavior of 
overwriting existing files when using fopen(..., "wx")

misc.c:1552: Test failed: overwrote existing file with mode wx

Br,
Ted

Den 2021-10-07 kl. 21:53, skrev Ted Lyngmo:
> ... but now something else failed.
>
> misc.c:550: Test failed: 9 should be blank
>
> I can't figure out how I broke "test_isblank" with my patch. That test 
> looks unrelated to anything that has to do with fopen(). Perhaps it 
> becomes obvious after some sleep :-)
>
> Br,
> Ted
>
> Den 2021-10-07 kl. 21:42, skrev Ted Lyngmo:
> > Den 2021-10-07 kl. 21:29, skrev Piotr Caban:
> > > ...
> > > Please also change the commit message to something like:
> > > ucrtbase: Add support for x mode in fopen.
> >
> > Ok, I've now made the changes you suggested. Many thanks for all the 
> > quick help!
> >
> > Br,
> > Ted

[Saulius Krasuckas]

Hello folks,

* On 2021-10-07 22:53, Ted Lyngmo wrote:
> misc.c:550: Test failed: 9 should be blank
>
> I can't figure out how I broke "test_isblank" with my patch. That test
> looks unrelated to anything that has to do with fopen(). Perhaps it
> becomes obvious after some sleep :-)

I'd use debugger and try adding two breakpoints: one at the misc.c:550 
(or misc.c:1552) and when it the stops, the second one at the start of 
your newly added code. And then I'd try stepping into/over the used 
subroutines.

Then all "Win1909+" and "Win10" bot runs contains similar failure [1]:

--- quote ---
dlls/ucrtbase/tests/misc.c

1b34:misc: 2 tests executed (0 marked as todo, 0 failures), 0 skipped.
misc.c:550: Test failed: 9 should be blank
16d4:misc: 198552 tests executed (0 marked as todo, 1 failure), 0 
skipped.
ucrtbase:misc:16d4 done (1) in 0s
--- quote ---

And all "Win10L" runs has it too plus more [2]:

--- quote ---
dlls/ucrtbase/tests/misc.c

1d04:misc: 2 tests executed (0 marked as todo, 0 failures), 0 skipped.
misc.c:550: Test failed: 9 should be blank
misc.c:799: Test failed: fma(inf, 0.000000, 0.000000) got errno -1
misc.c:799: Test failed: fma(0.000000, inf, 0.000000) got errno -1
misc.c:799: Test failed: fma(inf, 1.000000, -inf) got errno -1
misc.c:799: Test failed: fma(-inf, 1.000000, inf) got errno -1
misc.c:799: Test failed: fma(1.000000, inf, -inf) got errno -1
misc.c:799: Test failed: fma(1.000000, -inf, inf) got errno -1
0eec:misc: 198552 tests executed (0 marked as todo, 7 failures), 0 
skipped.
ucrtbase:misc:0eec done (7) in 0s
--- quote ---

This happens since at least 2021-07-27. [4]
Also please note the change in pattern of error count for these OS 
versions: [5]

...
1, 1, 7
1, 7, 7
1, 7, 1
...

--- quote ---
1cddd8d5715d	Aug 31	0	0	0	0	1	1	7	1	shortlog
21c4a2543796	Aug 30	0	0	0	0	1	1	7	1	shortlog
8e2df64cf897	Aug 27	0	0	0	0	1	7	7	1	shortlog
07ecdf6ce275	Aug 26	0	0	0	0	1	7	1	1	shortlog
4a18232e455d	Aug 25	0	0	0	0	1	7	1	1	shortlog
--- quote ---

Might be worth investigating the native environments first.  Maybe the 
DLL versions or changes in guest OS templates?
(Ccing Francois too, just in case)

S.

[1] 
http://test.winehq.org/data/5636088871714f2a2de9e543eb66f944ce188edc/win2004...
[2] 
http://test.winehq.org/data/5636088871714f2a2de9e543eb66f944ce188edc/win21H1...
[3] http://test.winehq.org/data/tests/ucrtbase:misc.html
[4] 
https://web.archive.org/web/20210923213413/http://test.winehq.org/data/f1023...
[5] 
https://test.winehq.org/data/tests/ucrtbase:misc.html#:~:text=8e2df64cf897,s...

[Ted Lyngmo]

Howdy Saulius!

I made two patches Yesterday where I tried fixing bug 
https://bugs.winehq.org/show_bug.cgi?id=51846.

Patch 1: msvcrt: https://testbot.winehq.org/JobDetails.pl?Key=99682

This patch makes programs compiled by Visual Studio and that works as 
expected in native Windows also work in Wine.

The only problem with my added test seems to be that programs 
cross-compiled with mingw does not work on native Windows so the tests fail.

Patch 2: ucrtbase: https://testbot.winehq.org/JobDetails.pl?Key=99684

This patch fails less tests but does not solve the bug at all - so I 
don't think it's worth looking into why this patch also made totally 
unrelated tests fail. I think this patch can be abandoned.

I'm not sure where to go from here.

Br,
Ted


On 2021-10-08 09:14, Saulius Krasuckas wrote:
> Hello folks,
>
> * On 2021-10-07 22:53, Ted Lyngmo wrote:
> > misc.c:550: Test failed: 9 should be blank
> >
> > I can't figure out how I broke "test_isblank" with my patch. That test
> > looks unrelated to anything that has to do with fopen(). Perhaps it
> > becomes obvious after some sleep :-)
>
> I'd use debugger and try adding two breakpoints: one at the misc.c:550 
> (or misc.c:1552) and when it the stops, the second one at the start of 
> your newly added code. And then I'd try stepping into/over the used 
> subroutines.
>
> Then all "Win1909+" and "Win10" bot runs contains similar failure [1]:
>
> --- quote ---
> dlls/ucrtbase/tests/misc.c
>
> 1b34:misc: 2 tests executed (0 marked as todo, 0 failures), 0 skipped.
> misc.c:550: Test failed: 9 should be blank
> 16d4:misc: 198552 tests executed (0 marked as todo, 1 failure), 0 skipped.
> ucrtbase:misc:16d4 done (1) in 0s
> --- quote ---
>
> And all "Win10L" runs has it too plus more [2]:
>
> --- quote ---
> dlls/ucrtbase/tests/misc.c
>
> 1d04:misc: 2 tests executed (0 marked as todo, 0 failures), 0 skipped.
> misc.c:550: Test failed: 9 should be blank
> misc.c:799: Test failed: fma(inf, 0.000000, 0.000000) got errno -1
> misc.c:799: Test failed: fma(0.000000, inf, 0.000000) got errno -1
> misc.c:799: Test failed: fma(inf, 1.000000, -inf) got errno -1
> misc.c:799: Test failed: fma(-inf, 1.000000, inf) got errno -1
> misc.c:799: Test failed: fma(1.000000, inf, -inf) got errno -1
> misc.c:799: Test failed: fma(1.000000, -inf, inf) got errno -1
> 0eec:misc: 198552 tests executed (0 marked as todo, 7 failures), 0 skipped.
> ucrtbase:misc:0eec done (7) in 0s
> --- quote ---
>
> This happens since at least 2021-07-27. [4]
> Also please note the change in pattern of error count for these OS 
> versions: [5]
>
> ...
> 1, 1, 7
> 1, 7, 7
> 1, 7, 1
> ...
>
> --- quote ---
> 1cddd8d5715d    Aug 31    0    0    0    0    1    1    7    1    shortlog
> 21c4a2543796    Aug 30    0    0    0    0    1    1    7    1    shortlog
> 8e2df64cf897    Aug 27    0    0    0    0    1    7    7    1    shortlog
> 07ecdf6ce275    Aug 26    0    0    0    0    1    7    1    1    shortlog
> 4a18232e455d    Aug 25    0    0    0    0    1    7    1    1    shortlog
> --- quote ---
>
> Might be worth investigating the native environments first.  Maybe the 
> DLL versions or changes in guest OS templates?
> (Ccing Francois too, just in case)
>
> S.
>
> [1] 
> http://test.winehq.org/data/5636088871714f2a2de9e543eb66f944ce188edc/win2004...
>
> [2] 
> http://test.winehq.org/data/5636088871714f2a2de9e543eb66f944ce188edc/win21H1...
>
> [3] http://test.winehq.org/data/tests/ucrtbase:misc.html
> [4] 
> https://web.archive.org/web/20210923213413/http://test.winehq.org/data/f1023...
>
> [5] 
> https://test.winehq.org/data/tests/ucrtbase:misc.html#:~:text=8e2df64cf897,s...

[Piotr Caban]

On 10/8/21 9:41 AM, Ted Lyngmo wrote:
> Patch 1: msvcrt: https://testbot.winehq.org/JobDetails.pl?Key=99682
>
> This patch makes programs compiled by Visual Studio and that works as 
> expected in native Windows also work in Wine.
>
> The only problem with my added test seems to be that programs 
> cross-compiled with mingw does not work on native Windows so the tests 
> fail.
> It doesn't look right. I'm not sure how you're testing it but as your 
> test shows msvcrt.dll is not supposed to handle x mode.
> Patch 2: ucrtbase: https://testbot.winehq.org/JobDetails.pl?Key=99684
>
> This patch fails less tests but does not solve the bug at all - so I 
> don't think it's worth looking into why this patch also made totally 
> unrelated tests fail. I think this patch can be abandoned.
>
> I'm not sure where to go from here.
> Are you sure you have tested it correctly? Did you recompile ucrtbase 
> with your patch?

The "misc.c:550: Test failed: 9 should be blank" failure is not related 
to your patch and can be ignored. But there are other failures caused by 
your patch:
misc.c:372: Test failed: unexpected call global_invalid_parameter_handler
misc.c:1548: Test failed: creating file with mode wx failed
misc.c:372: Test failed: unexpected call global_invalid_parameter_handler
misc.c:372: Test failed: unexpected call global_invalid_parameter_handler
misc.c:372: Test failed: unexpected call global_invalid_parameter_handler
misc.c:1557: Test failed: creating file with mode w+x failed
misc.c:372: Test failed: unexpected call global_invalid_parameter_handler
misc.c:372: Test failed: unexpected call global_invalid_parameter_handler

This generally shows that x mode is not supported in older version of 
ucrtbase. While this needs to be fixed before the patch can go into wine 
I would suggest focusing on understanding why the patch doesn't fix your 
test app first (I guess it's a mistake while testing).

Thanks,
Piotr

[Ted Lyngmo]

Hi Piotr!

On 2021-10-08 10:18, Piotr Caban wrote:
> On 10/8/21 9:41 AM, Ted Lyngmo wrote:
> > Patch 1: msvcrt: https://testbot.winehq.org/JobDetails.pl?Key=99682
> >
> > This patch makes programs compiled by Visual Studio and that works as 
> > expected in native Windows also work in Wine.
> >
> > The only problem with my added test seems to be that programs 
> > cross-compiled with mingw does not work on native Windows so the tests 
> > fail.
>
> It doesn't look right. I'm not sure how you're testing it but as your 
> test shows msvcrt.dll is not supposed to handle x mode.

To me it looks like the opposite - that msvcrt.dll is supposed to handle it.

This is how I tested:

* I wrote a program using fopen(..., "wx") and compiled it with Visual
   Studio 2019. It works as it should in native Windows.

* I executed the binary compiled above in Fedora 34 with Wine
   6.16-staging, which printed
   0104:err:msvcrt:msvcrt_get_flags incorrect mode flag: x
   ... and overwrote the existing file.

* I downloaded the Wine source and compiled it to confirm that the bug
   still exists on master.

* I made a patch in dlls/msvcrt/file.c (msvcrt_get_flags) to add
   support for "x" and recompiled Wine clean.

* I executed the same program mentioned above using the Wine version I
   just compiled. The message "err:msvcrt:msvcrt_get_flags" was gone and
   the program instead behaved as it should. An existing file wasn't
   overwritten. If the file doesn't exist, it's created.

So, at this point I was pretty sure that was everything I needed to do. 
However, I then cross-compiled the same program with 
i686-w64-mingw32-gcc (Fedora MinGW 10.3.1-2.fc34, the same compiler used 
when building Wine). The same binary

* behaves properly in Wine.
* fails in native Windows.
> > Patch 2: ucrtbase: https://testbot.winehq.org/JobDetails.pl?Key=99684
> >
> > This patch fails less tests but does not solve the bug at all - so I 
> > don't think it's worth looking into why this patch also made totally 
> > unrelated tests fail. I think this patch can be abandoned.
> >
> > I'm not sure where to go from here.
>
> Are you sure you have tested it correctly? Did you recompile ucrtbase 
> with your patch?

I recompiled Wine after "make clean", "git clean -fdx" and "find -name 
'*.dll'" (which didn't show any dll's).
> The "misc.c:550: Test failed: 9 should be blank" failure is not related 
> to your patch and can be ignored. But there are other failures caused by 
> your patch:
> misc.c:372: Test failed: unexpected call global_invalid_parameter_handler
> misc.c:1548: Test failed: creating file with mode wx failed
> misc.c:372: Test failed: unexpected call global_invalid_parameter_handler
> misc.c:372: Test failed: unexpected call global_invalid_parameter_handler
> misc.c:372: Test failed: unexpected call global_invalid_parameter_handler
> misc.c:1557: Test failed: creating file with mode w+x failed
> misc.c:372: Test failed: unexpected call global_invalid_parameter_handler
> misc.c:372: Test failed: unexpected call global_invalid_parameter_handler
>
> This generally shows that x mode is not supported in older version of 
> ucrtbase. While this needs to be fixed before the patch can go into wine 
> I would suggest focusing on understanding why the patch doesn't fix your 
> test app first (I guess it's a mistake while testing).

With the ucrtbase-patch, the app (compiled with VS2019) did not work 
since it still overwrote existing files. The .exe seems to need my patch 
to be compiled into msvcrt.dll for it to take effect.

Cross-compiling the app with mingw and running it on native Windows 
gives the result you showed above. It's the same result as with the 
msvcrt-patch. I guess Wine isn't involved at all here?

Could it be mingw that makes some mistake?

Br,
Ted

[Piotr Caban]

Hi Ted,

I don't know all the options you have used while compiling the 
executable. I guess you might be linking to different version of runtime 
in mingw case.

Let's move the discussion to the bug 
(https://bugs.winehq.org/show_bug.cgi?id=51846).

Thanks,
Piotr

[Ted Lyngmo]

Hi again Piotr and thanks for taking a look at this!

I've created attachments with the two .exe's (compiled with VS2019 and 
mingw) and winedumps for both.

I updated the source of the test program slightly to make it clearer and 
to make it clean up. I accidentaly added the source as a comment 
(comment #2) but it's also there as an attachment too, so just disregard 
comment #2.

Cheers,
Ted

Den 2021-10-08 kl. 13:04, skrev Piotr Caban:
> Hi Ted,
>
> I don't know all the options you have used while compiling the 
> executable. I guess you might be linking to different version of runtime 
> in mingw case.
>
> Let's move the discussion to the bug 
> (https://bugs.winehq.org/show_bug.cgi?id=51846).
>
> Thanks,
> Piotr

[Marvin]

Hi,

While running your changed tests, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?

Full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=99682

Your paranoid android.


=== w7u_2qxl (32 bit report) ===

msvcrt:
file.c:119: Test failed: creating file with mode wx failed
file.c:129: Test failed: creating file with mode w+x failed

=== w7u_adm (32 bit report) ===

msvcrt:
file.c:119: Test failed: creating file with mode wx failed
file.c:129: Test failed: creating file with mode w+x failed

=== w7u_el (32 bit report) ===

msvcrt:
file.c:119: Test failed: creating file with mode wx failed
file.c:129: Test failed: creating file with mode w+x failed

=== w8 (32 bit report) ===

msvcrt:
file.c:119: Test failed: creating file with mode wx failed
file.c:129: Test failed: creating file with mode w+x failed

=== w8adm (32 bit report) ===

msvcrt:
file.c:119: Test failed: creating file with mode wx failed
file.c:129: Test failed: creating file with mode w+x failed

=== w864 (32 bit report) ===

msvcrt:
file.c:119: Test failed: creating file with mode wx failed
file.c:129: Test failed: creating file with mode w+x failed

=== w1064v1507 (32 bit report) ===

msvcrt:
file.c:119: Test failed: creating file with mode wx failed
file.c:129: Test failed: creating file with mode w+x failed

=== w1064v1809 (32 bit report) ===

msvcrt:
file.c:119: Test failed: creating file with mode wx failed
file.c:129: Test failed: creating file with mode w+x failed

=== w1064 (32 bit report) ===

msvcrt:
file.c:119: Test failed: creating file with mode wx failed
file.c:129: Test failed: creating file with mode w+x failed

=== w1064_tsign (32 bit report) ===

msvcrt:
file.c:119: Test failed: creating file with mode wx failed
file.c:129: Test failed: creating file with mode w+x failed

=== w10pro64 (32 bit report) ===

msvcrt:
file.c:119: Test failed: creating file with mode wx failed
file.c:129: Test failed: creating file with mode w+x failed

=== w864 (64 bit report) ===

msvcrt:
file.c:119: Test failed: creating file with mode wx failed
file.c:129: Test failed: creating file with mode w+x failed

=== w1064v1507 (64 bit report) ===

msvcrt:
file.c:119: Test failed: creating file with mode wx failed
file.c:129: Test failed: creating file with mode w+x failed

=== w1064v1809 (64 bit report) ===

msvcrt:
file.c:119: Test failed: creating file with mode wx failed
file.c:129: Test failed: creating file with mode w+x failed

=== w1064 (64 bit report) ===

msvcrt:
file.c:119: Test failed: creating file with mode wx failed
file.c:129: Test failed: creating file with mode w+x failed

=== w1064_2qxl (64 bit report) ===

msvcrt:
file.c:119: Test failed: creating file with mode wx failed
file.c:129: Test failed: creating file with mode w+x failed

=== w1064_tsign (64 bit report) ===

msvcrt:
file.c:119: Test failed: creating file with mode wx failed
file.c:129: Test failed: creating file with mode w+x failed

=== w10pro64 (64 bit report) ===

msvcrt:
file.c:119: Test failed: creating file with mode wx failed
file.c:129: Test failed: creating file with mode w+x failed

=== w10pro64_ar (64 bit report) ===

msvcrt:
file.c:119: Test failed: creating file with mode wx failed
file.c:129: Test failed: creating file with mode w+x failed

=== w10pro64_he (64 bit report) ===

msvcrt:
file.c:119: Test failed: creating file with mode wx failed
file.c:129: Test failed: creating file with mode w+x failed

=== w10pro64_ja (64 bit report) ===

msvcrt:
file.c:119: Test failed: creating file with mode wx failed
file.c:129: Test failed: creating file with mode w+x failed

=== w10pro64_zh_CN (64 bit report) ===

msvcrt:
file.c:119: Test failed: creating file with mode wx failed
file.c:129: Test failed: creating file with mode w+x failed