[ANNOUNCEMENT] Updated: vim-7.3.003-1

Corinna Vinschen corinna-cygwin@cygwin.com
Fri Aug 20 18:35:00 GMT 2010

On Aug 20 11:39, Christopher Faylor wrote:
> On Fri, Aug 20, 2010 at 05:09:20PM +0200, Thorsten Kampe wrote:
> >* Corinna Vinschen (Fri, 20 Aug 2010 16:33:17 +0200)
> >> Not weird at all.  I could track this down to a point in Cygwin where
> >> it neglects to close a handle to a symlink when instructed to follow
> >> symlinks to their target.  I checked in a patch.  Please test the DLL
> >> I uploaded at
> >> 
> >>   http://cygwin.de/cygwin-ug-177/newer-cygwin1.dll.bz2
> >>   (md5sum compressed   5eab6680538279206bf23c54244825d2)
> >>   (md5sum uncompressed e4833a601edad1571a9c6e0352a8e381)
> >> 
> >> which contains the fix.  This should not leave the stray handles to
> >> vi, vim, etc in zsh.  And the side-effect should be that setup.exe
> >> does not complain anymore in the original scenario.
> >
> >Yes, the evil handles are gone.
> Sounds like a reason for a new cygwin release.

Definitely.  I was planning to release 1.7.7 this weekend or early
next week.

> Did we ever come to a consensus on what to do with the Cygwin cwd stuff?
> It sounded like people were reluctantly agreeing with my reluctant
> proposal to not set the windows cwd to the pipe pseudo-location unless
> chdir was explicitly called.

I'm not really convinced that this is a good solution.  It is somewhat
half-half, sticking to Win32 backward compatibility but not quite.  This
hits Cygwin applications in the back in the first place.  How many POSIX
tools actually call chdir?  Most shells, but otherwise?

My POV is the same as expressed in

We should stick to POSIX (well, Linux, BSD, whatever) compatibility as
much as possible.  Drawbacks in the Win32 API are not really breaking
backward compatibility since compatibility means POSIX compatibility,
not Win32 compatibility.  The latter is the task of Mingw.

If this POV doesn't get much backup through the discussion process, the
only really useful solution is, IMHO, this.  Since POSIX actually allows
rmdir(2) to return EBUSY, we should go the entire way:

- If the path is a virtual path, call SetCurrentDirectory (//?/PIPE/).
- Otherwise call SetCurrentDirectory (new_cwd).
- If that fails, call NtCreateFile to get a handle and
  SetCurrentDirectory (//?/PIPE/) for the sake of the Win32 API.

Since the workaround I created originally doesn't work since Vista
anyway, we keep full Win32 backward compatibility and just give up
on the Linux-like capability to rename or remove a CWD, while still
maintaining POSIX compatibility.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-developers mailing list