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 15:45:00 GMT 2010


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

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


Corinna

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