Re: cd -s symlink hangs (sometimes?)

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mar 22, 12:54pm, Peter Stephenson wrote:
}
} 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 did a quick search of the zsh-workers archives and that code appears
to predate the earliest messages from the mailing list that are there,
or at least to predate the habit of mailing patches to the lists.  So
if it was hacked in without fixing the rest of the structure, it was
hacked in a very long time ago.

Anyway, as best I can tell the reason for the open("..") is to cause
an error to be returned from restoredir() later.  At the code above,
if open(".") fails but zgetdir() succeeds, we can stat(".") but not
read it.  So the code attempts to arrange that restoredir() will cd
into a directory that we CAN read (".." in this case), but leaves
mismatched ino,dev information in the dirsave struct so restoredir()
will return nonzero, causing lchdir() to return -2.

In the course of looking at this I think I've spotted another problem,
which possibly only affects filesystems where a double slash at the
root means something different (mainly Cygwin at this point).  Have a
look at zchdir() and consider the consequences of passing it a file
name consisting entirely of "/" characters repeated PATH_MAX+N times.