On Mar 16 08:51, Brian Dessent wrote:
> Corinna Vinschen wrote:
>
> > Actually that was intended, but unfortunately the current path handling
> > deliberately creates DOS paths with slashes (in find_exec) right now,
> > so that doesn't work ATM.
>
> I guess what I don't understand is how it's bot
Corinna Vinschen wrote:
> Actually that was intended, but unfortunately the current path handling
> deliberately creates DOS paths with slashes (in find_exec) right now,
> so that doesn't work ATM.
I guess what I don't understand is how it's both possible for
open("c:/foo/bar.exe") to succeed and
Corinna Vinschen wrote:
> len is a const value. Checking len for being < 65536 is a constant
> expression which always results in qddlen being 65535 so the ?: is
> a noop, more or less.
Yeah, I realized that, and the compiler should optimize it away
completely. I put it explicitly as a test in
On Sun, Mar 16, 2008 at 04:22:13PM +0100, Corinna Vinschen wrote:
>On Mar 16 03:14, Brian Dessent wrote:
>> I debugged this and found the
>> strangest thing, when you call QueryDosDevice (NULL, fnbuf, len) to get
>> the list of all DOS devices and len >= 65536, Win32 always returns 0
>> with GetL
On Sun, Mar 16, 2008 at 03:14:40AM -0700, Brian Dessent wrote:
>
>It looks like handle_to_fn is again acting up for named pipes. A
>representative strace snippet looks something like this:
>
> 428 108008 [main] readlink 3048 handle_to_fn: nt name
>'\Device\NamedPipe\Win32Pipes.082c.0003'
On Mar 16 03:14, Brian Dessent wrote:
> I debugged this and found the
> strangest thing, when you call QueryDosDevice (NULL, fnbuf, len) to get
> the list of all DOS devices and len >= 65536, Win32 always returns 0
> with GetLastError set to ERROR_MORE_DATA. Since len was being set as
> "sizeof
On Mar 16 00:23, Brian Dessent wrote:
> There's a small buglet in normalize_posix_path in that it doesn't see
> c:/foo/bar type paths as being win32 and so it treats them as a relative
> path and prepends cwd.
Actually that was intended, but unfortunately the current path handling
deliberately cre
On Mar 15 06:49, Brian Dessent wrote:
> Anyway, the attached is the result of what happened when I started with
> the Cygwin code and whittled it down. It fixes the bug in the
> grandparent of this email where it was reading the Win32 path out of a
> shortcut that didn't have an ITEMIDLIST, and it
It looks like handle_to_fn is again acting up for named pipes. A
representative strace snippet looks something like this:
428 108008 [main] readlink 3048 handle_to_fn: nt name
'\Device\NamedPipe\Win32Pipes.082c.0003'
1548 109556 [main] readlink 3048 normalize_posix_path: src
\Device
There's a small buglet in normalize_posix_path in that it doesn't see
c:/foo/bar type paths as being win32 and so it treats them as a relative
path and prepends cwd. Things go downhill from there. The testcase
that exposed this was insight failing to load because some of the tcl
parts use win32
10 matches
Mail list logo
