Re: cd -s symlink hangs (sometimes?)

[Peter Stephenson <pws@csr.com>]

Bart Schaefer wrote:
> 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)

I don't think that's likely to work anyway, though...  if we can't
open(".") because of *directory* permissions, that means we won't be
able to open("..") either.  They're both just entries in the current
directory (that happen to have special meanings).  (It's because we can
only track up the hard-linked layout by laboriously opening the file
".."  in the current directory that it's all so complicated.)

> but leaves
> mismatched ino,dev information in the dirsave struct so restoredir()
> will return nonzero, causing lchdir() to return -2.

Presumably with similar effects to what we're seeing now,
i.e. mismatched diretories.  Sounds like another good reason for
completely rewriting the ("..")  thing.

> 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.

So if the initial chdir() fails, shouldn't we rewind the pointer to the
start (dir), then break out of the loop and return failure?  Or what
else?

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070