This is the mail archive of the
cygwin-patches
mailing list for the Cygwin project.
Re: [patch] cygcheck.cc update for cygpath()
On Mar 9 17:30, Brian Dessent wrote:
> Corinna Vinschen wrote:
> > The problem is that the cwd is stored as UNICODE_STRING with a
> > statically allocated buffer in the user parameter block. The
> > MaximumLength is set to 520. SetCurrentDirectory refuses to take paths
> > longer than that. In theory it would be possible to define a longer cwd
> > by defining a new buffer in the cwd's UNICODE_STRING. But I never tried
> > that. I don't really know if that's possible and what happens if you
> > call CreateProcess or, FWIW, any Win32 file access function after doing
> > that. Nobody keeps us from trying, but I have this gut feeling that
> > different NT versions will show different behaviour...
>
> How does this fit in with the practice of maintaining our own Cygwin CWD
> state separate from the Win32 CWD so that unlink(".") and the like can
> succeed? Or is that precisely how we are able to support a CWD >= 260?
Cygwin maintains its own cwd. It writes the directory path and handle
back to the user parameter block, but it does not do that if the path
gets longer than 259 chars. When a Cygwin process forks or execs
another Cygwin application, the cwd is inherited through the cygheap.
> If it is the case that we can only support a CWD >= 260 by faking it,
> i.e. not trying to sync the Win32 CWD to the actual long CWD, then it
> seems we are limited to two choices for how to deal with a long CWD in a
> non-Cygwin process: a) not supported, b) supported only through some
> special hook (such as cgf's idea of handle inheritance of the Cygwin CWD
> handle) or through relying on the shell to set PWD.
ACK.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat