[patch] cygcheck.cc update for cygpath()
Christopher Faylor
cgf-use-the-mailinglist-please@cygwin.com
Mon Mar 10 19:09:00 GMT 2008
On Mon, Mar 10, 2008 at 11:34:44AM +0100, Corinna Vinschen wrote:
>On Mar 9 19:20, Christopher Faylor wrote:
>> On Sun, Mar 09, 2008 at 08:55:09PM +0100, Corinna Vinschen wrote:
>> >On Mar 9 11:03, Brian Dessent wrote:
>> >> Christopher Faylor wrote:
>> >>
>> >> > I guess I misunderstood. I thought that the current working directory
>> >> > could be derived through some complicated combination of Nt*() calls.
>> >>
>> >> I could be wrong here but the way I understood it, there is no concept
>> >> of a working directory at the NT level, that is something that is
>> >> maintained by the Win32 layer.
>> >
>> >That's right. NT doesn't have a notion what a cwd is. It only has the
>> >OBJECT_ATTRIBUTES structure which defines an object by an absolute path,
>> >or by a path relative to a directory handle.
>> >
>> >The cwd is maintained by kernel32.dll in a per-process structure called
>> >RTL_USER_PROCESS_PARAMETERS. The cwd is stored as path (always with
>> >trailing backslash) and as handle.
>>
>> Duh, right. I knew that. I've seen the code.
>>
>> So, maybe we could make sure the handle was inherited and pass it along
>> in a _CYGWIN_PWD=0x239487 format to the child?
>
>Well, sure, we could do that. But here's still a small problem.
>
>The Win32 functions like CreateFileW don't have a way to use the
>directory handle together with the relative path name as the native NT
>functions have. So, to be able to create an absolute path name, the
>application would have to find out the path the handle refers to using
>the native NT function ZwQueryObject. What it gets, however, is not
>directly usable with Win32 functions:
>
> Input path: c:\home\cgf
> Equivalent Win32 long path: \\?\c:\home\cgf
>
> ZwQueryObject returns: \Device\HarddiskVolume1\home\cgf
>
>By iterating through the DOS device list returned by QueryDosDevice the
>application could now find out that C: is a NT symlink to
>\Device\HarddiskVolume1 and then in turn create the path \\?\C:\home\cgf
>from that. Sounds rather too complicated to me.
That much I do understand since I've been struggling with that issue trying
to get pipes to work reliably.
However, I don't understand what a mingw app would see when it is started
from Cygwin now. What would a standard windows app think that its cwd would
be if it's cd'ed deep into a 32K long path.
cgf
More information about the Cygwin-patches
mailing list