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 To: "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> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , 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