X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-0.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,TW_CG
X-Spam-Check-By:	sourceware.org
X-USANET-Source:	165.212.120.254 IN aeolus AT electric-cloud DOT com s1hub1.EXCHPROD.USA.NET
X-USANET-MsgId:	XID187oHkT5V6648Xo1
From:	John Carey <aeolus AT electric-cloud DOT com>
To:	"cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Date:	Wed, 11 Aug 2010 19:55:56 +0000
Subject:	RE: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
Message-ID:	<3C031C390CBF1E4A8CE1F74DE7ECAF3A140684F0B0@MBX8.EXCHPROD.USA.NET>
References:	<3C031C390CBF1E4A8CE1F74DE7ECAF3A140684F0AA AT MBX8 DOT EXCHPROD DOT USA DOT NET>,<20100811084926 DOT GC26152 AT calimero DOT vinschen DOT de>
In-Reply-To:	<20100811084926.GC26152@calimero.vinschen.de>
MIME-Version:	1.0
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

On Aug 11 01:49 Corinna Vinschen wrote:
> On Aug 10 21:53, John Carey wrote:
> > Now, where is Windows stuffing the extra copy of the directory handle?
> > In those reference-counted heap-allocated directory objects.  Stepping
> > through the machine code under Windows 7 I see SetCurrentDirectory()
> > updating a global pointer ("ntdll!RtlpCurDirRef") to one such object,
> > under the protection of a critical section ("ntdll!FastPebLock").
> > Despite mentioning "Peb" in the name, neither global's address is
> > computed using "FS:".  The global pointer points to a heap-allocated
> > block that starts with a reference count followed by a copy of the
> > directory handle value, and apparently includes other data as well.
> > SetCurrentDirectory() swaps in a new such block, and decrements the
> > counter on the old block, and if that reaches 0, closes the handle.
> > Anyway, this block appears to be where the old current directory
> > handle value persists past the changes made by cwdstuff::set().
>=20
> ...and that handle is used in subsequent calls and potentially is a
> handle to another object in the meantime.
>=20
> I do basically agree with cgf that it's your own problem if you use
> Win32 calls in your Cygwin app.  OTOH, I see that this can trip up
> potential handle problems in the DLL itself.
>=20
> Unfortunately that means there's no Win32-safe way to set a new
> directory handle as cwd in Vista and later anymore.  Since there's no
> official API to set the cwd using a directory handle, there's no way to
> set the Win32 cwd to a directory with restricted permissions.
> This *is* frustrating.
>=20
> I'll look into another solution.  Probably we will have to call
> SetCurrentDirectory again and ignore any error.  I don't accept the
> aforementioned restriction for POSIX calls.

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?

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

- Raw text -