I added a couple of extra debugging lines in mux.c, recompiled and ran it.
debug3: link( "/tmp/sshcontrol-f1b458a85cd2aa9d5c115abc12afee9f485ad6b0.XSLUj2BsBSDnTkhZ","/tmp/sshcontrol-f1b458a85cd2aa9d5c115abc12afee9f485ad6b0" ): 0 debug3: unlink( "/tmp/sshcontrol-f1b458a85cd2aa9d5c115abc12afee9f485ad6b0.XSLUj2BsBSDnTkhZ" ): 0
The ": 0" is the value of the int returned by the two calls. They are successful according to LINK(3POSIX) and UNLINK(3POSIX).
Seth Arnold is right. OpenSSH is doing the things in the right way.
But somehow the kernel (or could it be the libc?) is messing stuff around with link() and/or unlink().
I added a couple of extra debugging lines in mux.c, recompiled and ran it.
debug3: link( "/tmp/sshcontro l-f1b458a85cd2a a9d5c115abc12af ee9f485ad6b0. XSLUj2BsBSDnTkh Z","/tmp/ sshcontrol- f1b458a85cd2aa9 d5c115abc12afee 9f485ad6b0" ): 0 l-f1b458a85cd2a a9d5c115abc12af ee9f485ad6b0. XSLUj2BsBSDnTkh Z" ): 0
debug3: unlink( "/tmp/sshcontro
The ": 0" is the value of the int returned by the two calls. They are successful according to LINK(3POSIX) and UNLINK(3POSIX).
Seth Arnold is right. OpenSSH is doing the things in the right way.
But somehow the kernel (or could it be the libc?) is messing stuff around with link() and/or unlink().