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 Fri, Aug 20, 2010 at 07:55:24PM +0100, Andy Koppe wrote:
>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.

My reason for a compromise is that the messaging should be fairly clear.
If someone has a problem deleting their current directory then, add this
to your program:

chdir (".");

You don't need to do anything besides that.  The alternative of not
allowing this might mean some more complex programming of unfamiliar
software.

If someone has a problem with their Windows app then it will only
be because they called chdir(something).  In that case, the answer
is either "What did you expect?" followed by "Here's the workaround".

I just had another idea.  How about if we add a library or object file
which can be linked with an application:

gcc -o myhybridwincyg.exe myhybridwincyg.c -lsync_cyg_cwd

Cygwin would then honor a flag which controls whether the cwd is
automatically synced or not.  Maybe someone has already suggested this
(and hopefully I haven't derided the idea if so) but we could have a
(shudder) environment variable to control the behavior too.

set CYGWIN=wincwdsync

cgf


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