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 Thu, Aug 12, 2010 at 04:01:54PM +0200, Corinna Vinschen wrote:
>On Aug 12 09:54, Christopher Faylor wrote:
>> On Thu, Aug 12, 2010 at 03:30:08PM +0200, Corinna Vinschen wrote:
>> >On Aug 12 14:15, Andy Koppe wrote:
>> >> On 12 August 2010 13:50, Earnie wrote:
>> >> > Corinna Vinschen wrote:
>> >> >>
>> >> >> ??Or don't start the Win32 app at all if the path is not valid. However
>> >> >> ??we have to call SetCurrentDirectory at least once, for the first
>> >> >> ??Cygwin app, into a spot it doesn't block the aforementioned rmdir.
>> >> 
>> >> Uh oh, that might cause additional aggro.
>> >> 
>> >> >> ??C:\ comes to mind. ??It's the one directory which always exists and
>> >> >> ??it's not removable anyway.
>> >> >>
>> >> >
>> >> > That should be SYSTEMDRIVE and not a hard C:\. ??There is no guarantee that
>> >> > C: drive is present.
>> >> 
>> >> Or the Cygwin base directory? Or /bin, i.e. the directory the DLL is
>> >> in? These couldn't be deleted anyway, and it'd be slighty less
>> >> catastrophic if things went wrong there ...
>> >
>> >Another advantage: We get the Cygwin root dir for free
>> >(shared.cc::installation_root).
>> 
>> We are talking about just finding a place to cd to and not a place to put
>> random files when the path is too long right?
>
>We're talking about a place to always cd to.

I guess it really doesn't matter.

If we're talking about:

chdir("/proc");
CreateFile ("foo", ...);

and you're proposing that foo should show up in c:\cygwin or
c:\cygwin\bin or c:\windows\system32 then I don't much like any of those
choices.  Of course, in this case, the user did go out of their way to
go to a cygwin-specific location.  In the case of cd'ing to a long
directory name they could have had no idea that the program was doing
anything wrong.

I'm still very strongly opposed to the idea of having CreateFile put
files in random locations.  I don't really get how people think it's ok
to let CreateFile silently succeed but not do what's expected.

I've done some googling but I can't find an answer to this: Is it
possible to create a directory which can't be written to - even by a
privileged user?  If so, then we should always cd there when we can't
successfully call SetCurrentDirectory().

In the case of /proc we could just create the directory and write the
file there but I think that would be wrong too.

cgf


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