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

Christopher Faylor cgf-use-the-mailinglist-please@cygwin.com
Wed Aug 11 16:24:00 GMT 2010

On Wed, Aug 11, 2010 at 05:45:42PM +0200, Corinna Vinschen wrote:
>On Aug 11 11:28, Christopher Faylor wrote:
>> On Wed, Aug 11, 2010 at 05:17:27PM +0200, Corinna Vinschen wrote:
>> >On Aug 11 10:57, Christopher Faylor wrote:
>> >> On Wed, Aug 11, 2010 at 10:54:07AM -0400, Christopher Faylor wrote:
>> >> >4) Break path into convenient chunks and first change to an absolute path
>> >> >whose length is <= MAXPATHLEN and then change to relative paths whose
>> >> >lenghts are also <= MAXPATHLEN.
>> >> >
>> >> >I thought that this technique worked but maybe I'm mistaken.  If it does,
>> >> >it would be a foolproof but slow way of cd'ing to a long path.
>> >> 
>> >> Actually, it isn't exactly foolproof because it wouldn't be thread-safe
>> >> with Windows API functions.  We could make it threadsafe with cygwin
>> >> functions though.
>> >
>> >The problem is that it won't work.  The CWD restriction to a path of 259
>> >chars is an absolute one.
>> Ok, in that case, I think we should go as deep as possible before
>> stopping rather than placing someone in some random other directory.
>> That's seems to be what cmd.exe does, on XP at least.  And, I think
>I see what you're up to, but I don't quite understand what you mean,
>actually.  How is that supposed to work in cmd on XP?  What scenario are
>you refering to?

"As deep as possible".  You can cd to a path which is <= the max length
and then it fails with a "path not found" error or something like that.

>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:


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.  If you don't then you could end
up having a program creating files in a random unexpected directory.

>> Cygwin programs should still work regardless but Cygwin should set the
>> cwd for pure-windows programs in deepest possible directory path.
>> Or, even better, maybe a Windows program should fail entirely if you try
>> to execute it in a path which is too deep.
>That's what happens in Cygwin right now, and we *could* also do the
>same for all paths for which SetCurrentDirectory failed.
>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

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.

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.


More information about the Cygwin-developers mailing list