This is the mail archive of the
cygwin
mailing list for the Cygwin project.
RE: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
- From: John Carey <aeolus at electric-cloud dot com>
- To: "cygwin at cygwin dot com" <cygwin at cygwin dot com>
- Date: Thu, 2 Sep 2010 23:32:29 +0000
- Subject: RE: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
- References: <3C031C390CBF1E4A8CE1F74DE7ECAF3A140684F0AA@MBX8.EXCHPROD.USA.NET> <20100811084926.GC26152@calimero.vinschen.de> <3C031C390CBF1E4A8CE1F74DE7ECAF3A140684F0B0@MBX8.EXCHPROD.USA.NET> <AANLkTimpBCKzUioEarGiKMQbTjN+6s9iDYm_zzZ2Lxr9@mail.gmail.com>,<20100812081151.GT14202@calimero.vinschen.de>
On Aug 12 01:11, Corinna Vinschen wrote:
> On Aug 12 06:54, Andy Koppe wrote:
> > On 11 August 2010 20:55, John Carey wrote:
> > > So is your idea that if SetCurrentDirectory() fails because
> > > of path length or permissions, then Cygwin would just accept
> > > the failure and keep an internal record the
> > > POSIX current working directory and use that for all
> > > Cygwin calls, not the Win32 notion of current directory?
> >
> > Yes. The question then becomes what to do about the Win32 working
> > directory in that case.
>
> Actually, Cygwin accepts *any* directory it can open as CWD:
>
> - Directories which can only be opened under SE_BACKUP_NAME.
> - Directories with a length up to 32768 chars.
> - Virtual directories, which don't exist at all as filesystem-based
> paths, like /proc, /cygdrive, etc.
>
In Aug 17 10:15, Corinna Vinschen wrote:
> I just released 1.7.6-1.
...
> What changed since Cygwin 1.7.5:
> ================================
>
> - Cygwin handles the current working directory entirely on its own. The
> Win32 current working directory is set to an invalid path to be out of
> the way. This affects calls to the Win32 file API (CreateFile, etc.).
> See http://cygwin.com/htdocs/cygwin-ug-net/using.html#pathnames-win32-api
Thank you very much for the fix!
I've been running tests against Cygwin 1.7.6, and then 1.7.7,
and those sporadic, non-deterministic failures in CreatePipe
did stop after the 1.7.6 upgrade, and are still gone in 1.7.7.
I think it's been long enough to conclude that it is not just
the non-determinism--it really is fixed, as expected.
I understand that this issue opened a can of worms;
thanks again for your efforts to overcome those difficulties.
-- John
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple