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

Corinna Vinschen corinna-cygwin@cygwin.com
Wed Aug 11 17:14:00 GMT 2010

On Aug 11 12:24, Christopher Faylor wrote:
> On Wed, Aug 11, 2010 at 05:45:42PM +0200, Corinna Vinschen wrote:
> >There is no chance at all to set a cwd with a longer path than
> >MAX_PATH-1 in the Win32 API, not the faintest.
> Yes.  That's what I meant by: "Ok, in that case".  I conceded the point.
> >To the best of my knowledge, what you can see on XP and any other system
> >is only what cmd.exe does if the current CWD isn't supported by cmd.exe.
> >This is the case for UNC paths, and if you call cmd.exe from an UNC path,
> >it places itself in C:\Windows\system32.
> I wrote a script which created:
> c:\abc\abc\abc\abc\abc\...
> And cd'ed into each subdirectory.  Eventually cmd stopped.  I was
> proposing that we could allow Cygwin to cd as deep as necessary but
> windows programs would only go as deep as they could.  But, actually,
> when running a windows program, I think we should error out if the
> current directory path is > MAX_PATH.

Yes, that's what Cygwin already does.

> >However, that's not the actual problem.  I'm not talking about child
> >processes, but about the Win32 API within the same process.  As soon as
> >SetCurrentDirectory failed, the problem is where do we place the process
> >so that subsequent Win32 API calls still work, for a given value of
> >"work".  The path is not the one in the POSIX API, that's for sure.
> >So relative paths will lead somewhere else.  The question is, where do
> >we leads these calls?
> I think that we should find some way to make the windows functions fail
> entirely.  Having the functions not return an error seems entirely wrong
> to me.  We could create a "q" (or whatever): drive, cd there, and delete
> the drive.  I guess that wouldn't work if the user had used all 26 drive
> letters.

And you can't delete the drive if there's an open handle to it, can you?
But even if so, it sounds like a lot of work, just to get some invalid path.

> If we can't make it fail then I still think that the file should be
> created "up" the directory path, as close as you can get to Cygwin's
> notion of cwd.

So, "set it to the longest possible path prefix of Cygwin's cwd which is
still accepted by SetCurrentDirectory".

Just to be clear, that would only affect the process itself since Cygwin
still refuses to exec a native Win32 application if the cwd is > MAX_PATH,
just like today.

> Either that or we could take the unprecedented step of wrapping
> CreateFile.  Then the answer to the question of how to deal with the
> problem would be "Relink your program".  But I don't think I really want
> to go there.

Me neither.


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