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 12 August 2010 10:45, Corinna Vinschen wrote:
> 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
> all!

Perhaps that's the way to go then. As a nice side effect, it would
remove overhead that's unnecessary for the 99.99% of Cygwin programs
that don't mix chdir() and CreateFile(). And it makes sense too that
you'd need to use SetCurrentDirectory() with CreateFile(). The Win32
working directory would still need to be set appropriately when
invoking non-Cygwin programs.

The argument against of course if backward compatibility, i.e. such a
change would break programs that do depend on chdir() setting the
Win32 working directory. On the other hand, they're already partially
broken anyway for POSIX directories that don't have Win32 equivalents,
so making that brokenness more obvious might actually be a good thing.

Andy


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