This is the mail archive of the cygwin-developers 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: [ANNOUNCEMENT] Updated: vim-7.3.003-1


On 20 August 2010 19:35, Corinna Vinschen wrote:
>> 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
> 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.

I agree it should be either one way or the other, because the
compromise breaks both Win32 and Linux compatibility. While it does so
to a lesser degree than either of the full-blooded approaches, it adds
more unpredictability because behaviour depends on the non-obvious
implementation detail of whether a process calls chdir.

Now how important is being able to delete the current working
directory of a process. We've established that POSIX doesn't require
it, but Linux supports it. Was not being able to delete the current
working directory an issue that came up frequently with 1.5? Is anyone
aware of stuff that would break?

If not, I think sticking with full Win32 compatibility is the way to
go here, because we already know what problems that causes. Going the
Linux way (and fixing up cygutils and anything else depending on the
Win32 stuff) still remains as an option for later, should the
inability to delete the cwd of a process prove too much of a burden.

Andy


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