Re: cd -s symlink hangs (sometimes?)

[Mikael Magnusson <mikachu@gmail.com>]

2009/3/24 Peter Stephenson <pws@csr.com>:
> On Mon, 23 Mar 2009 12:27:14 +0000
> Peter Stephenson <pws@csr.com> wrote:
>> On Mon, 23 Mar 2009 12:46:10 +0100
>> Mikael Magnusson <mikachu@gmail.com> wrote:
>> > 2009/3/23 Peter Stephenson <pws@csr.com>:
>> > Trying the patch now and it does stop the leak... but you didn't think
>> > this adventure was over yet, did you?
>>
>> No, I definitely want to fix the diagnostics and at the least the internal
>> setting of pwd when a cd fails, but I'm not sure what a neat way is.
>
> On top of this, I've found another pre-existing bug down to poorly thought
> out code structure, which may be something to do with the side effect
> Mikael was seeing:  on failure, restoredir() could call upchdir()
> repeatedly because it thought it was doing a recursive glob since the "level"
> element wasn't initialised.  I only got this sometimes with an optimised
> compilation; before, I was using a debug build which didn't show it up at
> all.  I've now put the initialisation for a "struct dirsav" in a
> subroutine.
>
> For the diagnostics and pwd, I've just borrowed what the recursive handling
> in zsh/files does, which is cd to /, set pwd consistently, and report the
> error.  This is at least much better; an algorithm for fixing up the
> current directory even better is a good deal more complicated and given you
> can't cd to the correct directory in this case it's not clear how useful it
> is.  So I'm tempted to leave it at this.
>
> In addition to "cd -s", this may address theoretical problems with recursive
> globs under similar circumstances.

I wasn't able to make it happen, but is it possible that under some
circumstance, a command of the form
/unimportant/dir% ls **/*; rm -rf *
could now remove everything in my home directory?

-- 
Mikael Magnusson