This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: [ANNOUNCEMENT] Updated: vim-7.3.003-1
- From: Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Fri, 20 Aug 2010 14:41:00 -0400
- Subject: Re: [ANNOUNCEMENT] Updated: vim-7.3.003-1
- References: <4C6DAD71.106@acm.org> <20100820082433.GA28236@calimero.vinschen.de> <i4lqbd$s6v$1@dough.gmane.org> <20100820123708.GC11340@calimero.vinschen.de> <i4m0gv$7rj$1@dough.gmane.org> <i4m30p$7rj$2@dough.gmane.org> <20100820143317.GD11340@calimero.vinschen.de> <i4m5ro$5uf$1@dough.gmane.org> <20100820153937.GA844@ednor.casa.cgf.cx> <20100820183506.GA11775@calimero.vinschen.de>
- Reply-to: cygwin-developers at cygwin dot com
On Fri, Aug 20, 2010 at 08:35:06PM +0200, Corinna Vinschen wrote:
>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?
I can't believe that I'm arguing for the Windows API but to counter the
argument: How many POSIX applications are confused by the inability to
delete the current directory? I like that Cygwin allows you to do this
now but I'm wondering how much pain we'll be giving to previously
working hybrid Cygwin applications.
>My POV is the same as expressed in
>http://cygwin.com/ml/cygwin/2010-08/msg00541.html
>
>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.
Which workaround doesn't work on Vista? The one in 1.7.6?
cgf