1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set

Corinna Vinschen corinna-cygwin@cygwin.com
Thu Aug 12 09:45:00 GMT 2010

On Aug 12 10:36, Corinna Vinschen wrote:
> I had an overnight idea which I'll test today.  Basically, Cygwin still
> has the code to access the PEB directly.  So, what I intend to try is this:
>   bool invalid_path = false;
>   if incoming path is a virtual Cygwin dir
>     invalid_path = true;
>   else
>     invalid_path = !SetCurrentDirectoryW (incoming path);
>   if (invalid_path)
>     {
>       InterlockedExchange (PEB CWD handle, NULL);
>       NtClose (exchanged handle);
>       PEB CWD pathname = "---invalid path---";
>     }
> If that works as expected, this looks like an easy solution to me to
> disallow further path-relative WIn32 commands, if the CWD can't be
> handled by the Win32 API.
> I'll report back what I find.

Oh, darn!  I just stumbled over the *other* comment in cwdstuff::set,
which points to another problem with SetCurrentDirectory:

  Unlinking a cwd fails because SetCurrentDirectory seems to
  open directories so that deleting the directory is disallowed.
  The below code opens with *all* sharing flags set.

So, actually, if we still want to be able to delete a cwd under the nose
of another Cygwin process. we don't want to call SetCurrentDirectory at

And then again, my test code doesn't work anyway, at least not on
Windows 7.
I tested this by calling chdir ("/proc").  The CWD handle in the PEB
is set to NULL, the handle is closed, the path is set to "---invalid
path---" ...  and nevertheless CreateFile creates a file and a
subsequent call to GetCurrentDirectory returns the current working
directory as if I never touched the PEB.  Using INVALID_HANDLE_VALUE
instead of NULL doesn't help either.


Back to square one.


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

More information about the Cygwin-developers mailing list