On Sep 14 18:11, Corinna Vinschen wrote: > On Sep 14 10:12, Corinna Vinschen wrote: > > On Sep 13 19:47, John Carey wrote: > > > Anyway, it looks to me as if overwriting the path in an existing > > > VistaCwd instance would confuse RtlGetCurrentDirectory_U() and > > > probably other Win32 API functions. (It may be that the same is > > > true for the handle member; I have not tried to find that out.) > > > Cygwin should probably allocate a new VistaCwd instance, > > > as does the Win32 SetCurrentDirectory() implementation. > > > > Hmm, I'm still wondering. In theory we don't have to replace the > > directory name. We just have to InterlockedExchange the handle, since > > we only need to replace the original handle which does not allow > > sharing-for-delete with our own handle which does. > > > > All other border cases (virtual dir, directory with restricted rights) > > can be rightfully handled by setting the Win32 CWD to \\?\PIPE\ again. > > > > That's at least worth a try, isn't it? > > I applied the below patch to Cygwin CVS and it appears to work nicely.
Sorry, that wasn't what I was trying to say. Actually, I'm using this code just locally for now and put it up here for discussion and for curious testers. I intend to apply it only, if we can agree that it's sufficient. > The only potential race I can think of is, if another thread of the same > Cygwin process calls SetCurrentDirectory. I'm inclined to let this > situation slip through the cracks since SetCurrentDirectory will already > mess up a mixed-mode Cygwin process. > > The "wincap.has_transactions ()" is just for testing. If we can use > that code, I would replace is with something like > "wincap.has_messed_up_cwd_handling()" or so. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
