Cygwin CWD vs. Win32 CWD (was Re: [ANNOUNCEMENT] Updated: vim-7.3.003-1)

Corinna Vinschen
Thu Aug 26 19:24:00 GMT 2010

On Aug 26 16:17, Reini Urban wrote:
> 2010/8/26 Corinna Vinschen:
> > This case has been cited as a reply to the explicit question if somebody
> > knows an application which tried to unlink its own CWD.  It's still just
> > a border case, not the common case.
> I saw similar border cases only with this pattern:
> mkdir /tmp/$$
> chdir /tmp/$$
>   test my stuff
> rm -rf .
> And all the upstream maintainers so far were not reluctant to change
> that to remove the tempdir from outside.
> I was rather happy with the <= 1.7.5 behaviour, already had issues

The problem with the <= 1.7.5 behaviour was that it could potentially
result in handle muddle starting with Windows Vista, as has been
discussed on the main list.  Even it it worked in 99% of the cases,
it wasn't safe.  And to my long running disappointment there's no
other way to set a CWD by handle, neither in the Win32 API, nor in
the Rtl API.  That's the reason we need another solution.

> with the CWD being a pipe,
> and propose that the cwd as PIPE should be just optional behaviour,
> either by linking the
> new .o or by some magic ENV.
> I had PIPE issues so far with:
> * winclient for xemacs, which I'm extending.
> * perl t/cygwin.t testsuite (path comparison)

That's not overly helpful.  The question is *why* did it make problems?
If the winclient is a Cygwin application using only POSIX calls, it
should never have noticed this problem.  Ditto if it's a native Win32
application.  Only a Cygwin application using native Win32 API calls
would suffer a problem.  Like our own cygpath tool.  Same for the perl
test.  How can it fail if perl is a Cygwin application?  If it uses the
Win32 API to acces files, it's doing something wrong.


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