process_rename assumes hard links?

[Corinna Vinschen]

On Oct 10 11:03, Gert Doering wrote:
> 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).

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

Indeed.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat