[Bug 16948] tmpfile() fails when run from Unix path

http://bugs.winehq.org/show_bug.cgi?id=16948

Juan Lang  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]
             Status|UNCONFIRMED                 |NEW
          Component|-unknown                    |msvcrt
     Ever Confirmed|0                           |1
            Summary|tmpfile() write, seek(0) and|tmpfile() fails when run
                   |read does not return same   |from Unix path
                   |data                        |

--- Comment #6 from Juan Lang   2009-01-16 11:56:39 ---
Confirming, though I compiled like so:
winegcc -g test.c -lmsvcrt

Omitting -lmsvcrt didn't produce the crash, as it used gcc's libc instead.

Here's a snip from my backtrace (which has a little more info):
=>0 0x601cf01e MSVCRT_fwrite+0x2e(ptr=0x6019f7d6, size=5, nmemb=1, file=(nil))
[/home/juan/src/wine/dlls/msvcrt/file.c:2403] in msvcrt (0x0032fe88)
  1 0x6019f583 main+0x5f() [/home/juan/foo/tmp/test.c:9] in a.out (0x0032fed8)
  2 0x6019f6d8 __wine_spec_exe_entry+0x88(peb=0x7ffdf000)
[/home/juan/src/wine/dlls/winecrt0/exe_entry.c:36] in a.out (0x0032ff08)
  3 0x7b8762a8 start_process+0x98(arg=(nil))
[/home/juan/src/wine/dlls/kernel32/process.c:904] in kernel32 (0x0032ffe8)
  4 0x6413a697 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000)
0x601cf01e MSVCRT_fwrite+0x2e [/home/juan/src/wine/dlls/msvcrt/file.c:2403] in
msvcrt: movl     0x4(%edi),%eax
2403      if(file->_cnt) {

The problem is tmpfile() is returning NULL.  Here's a snip from a +relay log:
0009:Call msvcrt.tmpfile() ret=60321546
0009:Call KERNEL32.GetFileAttributesA(6038cc60 "\s8.") ret=6034bf27
0009:Ret  KERNEL32.GetFileAttributesA() retval=ffffffff ret=6034bf27
fixme:msvcrt:MSVCRT__sopen : pmode 0x7bca91a1 ignored
0009:Call KERNEL32.CreateFileA(6038cc60
"\s8.",c0010000,00000007,0032fdb0,00000004,04000080,00000000) ret=6034e85a
0009:Ret  KERNEL32.CreateFileA() retval=ffffffff ret=6034e85a

Note the path:  "\s8.".  tmpnam() returns a filename in the root directory of
whatever the current drive is:
  p = s + sprintf(s, "\s%s.", tmpstr);

The trouble comes about when running the test program from a Unix path. 
Copying it to somewhere in the c: drive causes it to succeed.

I'm guessing tmpnam() needs to be adjusted to return a file in %TMP%, based on
its description on MSDN, but without test cases to confirm it I'm not sure.