Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Thu, 6 Jun 2002 16:22:10 +0200
From: Pavel Tsekov <ptsekov AT syntrex DOT com>
Reply-To: Pavel Tsekov <cygwin AT cygwin DOT com>
Organization: Syntrex, Inc.
X-Priority: 3 (Normal)
Message-ID: <17118445663.20020606162210@syntrex.com>
To: cygwin AT cygwin DOT com
Subject: Re[2]: 1.3.11(CVS): Possible bug involving temp file generation
In-Reply-To: <20020605150849.GF15167@redhat.com>
References: <20020605132012 DOT 8086 DOT qmail AT web21002 DOT mail DOT yahoo DOT com>
 <12220356170 DOT 20020605154358 AT syntrex DOT com> <20020605150849 DOT GF15167 AT redhat DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

>>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/