This is the mail archive of the cygwin 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 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().
> 
> ...and that handle is used in subsequent calls and potentially is a
> handle to another object in the meantime.
> 
> 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.
> 
> 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.
> 
> 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


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