This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: Cygwin CWD vs. Win32 CWD (was Re: [ANNOUNCEMENT] Updated: vim-7.3.003-1)
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
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat