This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Wed, Aug 11, 2010 at 07:14:31PM +0200, Corinna Vinschen wrote:
>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.

Ok. I guess I should have checked the source.

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

I tried it before I sent the mail and it sure seems like you can.

>But even if so, it sounds like a lot of work, just to get some invalid
>path.

I couldn't think of any other way to get an invalid path.  You can't
delete a directory if someone is cd'ed to it, AFAIK, although maybe you
could rename it.

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

Yes, but I still think it should be an error.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]