Subject: Re[2]: 1.3.11(CVS): Possible bug involving temp file generation
From: Pavel Tsekov <[email-masked]>
To: [email-masked]
Date: Thu, 6 Jun 2002 16:22:10 +0200

>>Check this thread: http://cygwin.com/ml/cygwin/2002-06/msg00158.html
>>
>>I've looked at the strace log you've attached and I saw that the code
>>reached a point which it wasn't supposed to reach under Win9x/ME.
>>
>>This is the line from the strace.log - normally this won't be printed
>>on Win9x:
>> 2142   57784 [main] PATCH 601141 handle_to_fn: nt name ''
>>
>>NW> It worked like a charm :).  What was the problem and how did you solve it,
>>NW> if I might ask?

CF> Actually, it is not supposed to make it that far anywhere unless the file
CF> is opened from the command line in stdout.  I don't know how it could affect
CF> temp file generation.

I have a question - what is the return value of NtQueryObject () if
the ntdll.dll is not found i.e. you're executing on Win9x ? Is it 0 or
-1 ? It seems from the strace.log the it is 0 but I want to be sure.

If it is 0 there is a problem - see below:

  // This buffer is uninitialized, so it make contain random garbage
  // (or maybe not ?).
  // From the strace output we know that its first char is zero though
  // obviously we're lucky :).
  char win32_fn[MAX_PATH + 100];

  // sys_wcstombs is a macro which expands to:
  // #define sys_wcstombs(tgt,src,len) \
  //          WideCharToMultiByte((current_codepage==ansi_cp?CP_ACP:CP_OEMCP),0,(src),-1,(tgt),(len),NULL,NULL)
  //
  // In the case of WinME ntfn->Name.Length would be 0 (zero).
  // From the MSDN documentation on WideCharToMultiByte
  //   lpMultiByteStr
  //     [out] Points to the buffer to receive the translated string.
  //   cbMultiByte
  //     [in] Specifies the size, in bytes, of the buffer pointed to by
  //     the lpMultiByteStr parameter. If this value is zero, the function returns
  //     the number of bytes required for the buffer. (In this case, the lpMultiByteStr
  //     buffer is not used.)
  sys_wcstombs (win32_fn, ntfn->Name.Buffer, ntfn->Name.Length);
  debug_printf ("nt name '%s'", win32_fn);
  
  // We leave here with posix_fn an emptry string.
  if (!strncasematch (win32_fn, DEVICE_PREFIX, DEVICE_PREFIX_LEN)
      || !QueryDosDevice (NULL, fnbuf, sizeof (fnbuf)))
    return strcpy (posix_fn, win32_fn);

Later in dtable::init_std_file_from_handle we have this:

 path_conv pc;
 // The pointer which should be returned from build_fhandler_from_name
 // ()will be NULL if name is empty string, which will cause a segfault.
 build_fhandler_from_name (fd, name, handle, pc)->init (handle, myaccess,
                            pc.binmode ());

I have actually tested this on my machine by setting, from inside the
debugger, OBJECT_NAME_INFORMATION->Name.Length to 0 after the call to
NtObjectQuery (). This was necessary because I don't have access to
any Win9x machines.

Hope this helps and sounds plausible. Btw this can explain the problem
with 'patch' causing STATUS_ACCESS_VIOLATION (if you have checked the
log). It doesn't explain this though:

> NW> patch: **** can't create `/cygdrive/c/WINDOWS/TEMP/po319437' : Bad
> file

I have never looked at this issue - so if it was there and it was
fixed I dont't why. I was speaking only on the STATUS_ACCESS_VIOLATION
issue.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/