Re: unix_stream_connect and socket address resolution

Thanks Günther!

This example makes sense to me. The behavior still feels a little odd to
me, but I can understand the practical benefit of what you describe, and
also why changing it would definitely cause breakage.

I have one addendum to ask then which is: what if before the loop we
pre-resolve the parent directory as a concrete `struct path`, and then
on each iteration of the loop resolve only the final path component to
the socket itself? (That is a single-component lookup relative to the
pre-resolved parent, to be clear.)

Per your example, a legitimate server restart recreates the socket inode
in the same directory, so this still picks up the new socket and
reconnects, while avoiding the effect where a concurrent
ancestor-directory rename causes a wildly different socket to be
resolved. Hopefully this preserves the intended use-case.

Note that this does mean recreating the parent directory itself at the
same path would no longer be followed, and a rename/unlink of the pinned
parent would cause the lookup to fail rather than resolve elsewhere.
That seems like the intended, safer direction to me, but flagging it as
a deliberate semantic change rather than an accident.

If this sounds like an acceptable middle-ground to everyone, I'd be happy to implement it.

Cheers,

John