Re: cd -s symlink hangs (sometimes?)

[Mikael Magnusson <mikachu@xxxxxxxxx>]

2009/3/22 Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>:
> On Sat, 21 Mar 2009 00:15:24 +0100
> Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
>> For some more fun I tried this, and it does still break:
>> mkdir a
>> ln -s a b
>> cd a
>> chmod -x .
>> cd -s $PWD:h/b
>> #infinite loop here still
>
> This is basically the same problem.  I'm not sure why when the directory
> is restored wrongly and you end up in "/" you are seeing this infinite
> loop and I'm not, but it may just be a side effect.
>
> The problem is still the code I was scratching my head over before:
>
> #ifdef HAVE_FCHDIR
>    if (d->dirfd < 0 && (d->dirfd = open(".", O_RDONLY | O_NOCTTY)) < 0 &&
>        zgetdir(d) && *d->dirname != '/')
>        d->dirfd = open("..", O_RDONLY | O_NOCTTY);
> #endif
>
> It's now being executed, but we can't open "." any more.  So it's
> failing to save a fchdir-able directory for restoring, so after the "cd
> -s" fails we end up still in / again.
>
> I'm not sure if there's a full fix for this.  It can probably be handled
> better than it is at the moment, but apart from warning the user and
> making sure the shell knows what directory it's actually in I'm
> don't really know how.

I just noticed (ls -l /proc/$$/fd) that with this last commit, zsh now keeps
all my old directories open, even when I don't use -s or anything special.

zsh -f
% cd /var
% cd log
% cd /var/tmp
% cd /
% cd tmp
% ls -g /proc/$$/fd
total 0
[...]
lr-x------ 1 users 64 2009-03-23 00:03 4 -> /tmp #this is from cwd in
the first cd,
                                                 #not the final cd tmp
lr-x------ 1 users 64 2009-03-23 00:03 5 -> /var
lr-x------ 1 users 64 2009-03-23 00:03 6 -> /var/log
lr-x------ 1 users 64 2009-03-23 00:03 7 -> /var/tmp
lr-x------ 1 users 64 2009-03-23 00:03 8 -> /


-- 
Mikael Magnusson