process_rename assumes hard links?

Gert Doering gert at
Wed Oct 10 20:03:35 EST 2012


On Wed, Oct 10, 2012 at 10:10:43AM +0200, Miguel Oliveira wrote:
> Bottom line our filesystem does not support hard links and I think the problem is that process_rename assumes link(old path,newpath) will always return
> one. Shouldn't this situation, i.e., link returning a symlink, be contemplated in the code? 

I think that a link() implementation that creates a symlink is fundamentally
broken and needs to die.

Programs can reasonably expect that a link() call that returns success
has created hard links, and it is *safe* to then call unlink(old path) -
which is standard practice to atomically test-and-set lock files, for

If you return a symlink instead, you have now made an unsuspecting program
destroy its lock file, and created a dangling symlink instead.

If link() cannot create a hardlink, it must return an error code
(EOPNOTSUPP is what the FreeBSD manpage documents for this case).

(Of course this is outside the scope for the question you asked, but I
know that a filesystem with the semantics you have described will cause
problems for *lots* of programs)

USENET is *not* the non-clickable part of WWW!
Gert Doering - Munich, Germany                             gert at
fax: +49-89-35655025                        gert at

More information about the openssh-unix-dev mailing list