Mail Archives: cygwin/2002/06/06/10:22:44
>>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/
- Raw text -