[patch] cygcheck.cc update for cygpath()

Corinna Vinschen corinna-cygwin@cygwin.com
Mon Mar 10 10:35:00 GMT 2008

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.

The alternative would be to open files always with NtOpenFile/
NtCreateFile.  I had this vague idea that we should avoid that for the
MingW tools in utils. 

If you really think this is the better approach, ok with me, but if we
create an environment variable anyway, why not use $PWD or create
$_CYGWIN_PWD as *path* when starting a native application?  It would
allow to use standard Win32 functions without much hassle.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-patches mailing list