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 Aug 12 10:12, Christopher Faylor wrote:
> 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", ...);

No, as I mentioned in

  http://cygwin.com/ml/cygwin-developers/2010-08/msg00020.html

the problem is that *any* cwd set by SetCurrentDirectory has the problem
that the directory is not removable anymore due to the open flags used
in the NtOpenFile call in RtlSetCurrentDirectory_U.  Virtual Cygwin
directories, long path names, and directories with restricted permissions
are just additional problems.

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

That's what happens with the current code.  If you call chdir to a virtual
or too long path, the Windows CWD will stick to the last choice which
worked.

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

That's unfair.  We're trying to find a solution which works, and which
doesn't show too much surprising behaviour, without compromising Cygwin
capabilities used in the POSIX API.  I'm sorry if you don't like them so
far.

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

No.  I never came across a directory which is not writable under
SE_BACKUP_NAME conditions.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


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