process_rename assumes hard links?
vinschen at redhat.com
Thu Oct 11 00:39:48 EST 2012
On Oct 10 11:03, Gert Doering wrote:
> 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).
... or EPERM on Linux and Cygwin.
> (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)
Cygwin Project Co-Leader
More information about the openssh-unix-dev