This is the mail archive of the cygwin-patches mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] cygcheck.cc update for cygpath()


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]