[patch] cygcheck.cc update for cygpath()

[Brian Dessent]

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? 
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.

Brian