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

Reini Urban
Thu Aug 26 14:17:00 GMT 2010

2010/8/26 Corinna Vinschen:
> On Aug 26 12:51, Andy Koppe wrote:
>> On 26 August 2010 09:06, Corinna Vinschen wrote:
>> > On Aug 26 01:45, Christopher Faylor wrote:
>> >> >Actually, new idea: is there some reason why we don't just cd out of the
>> >> >way when we detect that a deletion of a directory failed?  We could try
>> >> >to set the current working directory in cases where it's possible, only
>> >> >setting it to the pipe location when we actually try to delete it.
>> >> >Wouldn't that pretty much solve the problem?
>> >>
>> >> Answering my own question: that would only catch the case where one program
>> >> was cd'ed to the location.  If another program also had the directory as
>> >> its current directory then the rmdir would fail.
>> >>
>> >> But is that an acceptable compromise?
>> >
>> > I don't think so.  The common case is that another process is holding
>> > the dir, not the own process.
>> You may well be right there, but IIRC, the only actual problem case
>> that's been cited in this discussion concerned the process' own
>> working directory:
>> On 20 August 2010 19:52, Reini Urban wrote:
>> > I had this case only once in a perl module, svn-bisect if I remember
>> > correctly and the maintainer quickly adjusted his linuxism to be more
>> > friendly to other platforms. i.e. working around rm `pwd` was not an
>> > issue at all.
> 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
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)

And git behaves strange (sudden crashes) but I'm not sure yet why.

More information about the Cygwin-developers mailing list