process_rename assumes hard links?

[Gert Doering]

Hi,

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

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)

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de