Re: I am confused about the configure rename managing hardlinks test.

[Eric Blake]

On 09/29/2017 06:13 PM, John E. Malmberg wrote:
> Hello,
> 
> I am confused about the rename managing hardlinks test.
> 
> It starts out with conftest.f as an empty file and conftest.fl as a hard
> link to conftest.f.
> 
> Step 1:
>     rename ("conftest.f", "conftest.f1")
> 
> I would expect after a success, conftest.f would no longer exist, only
> conftest.f1.

Sadly, your expectations are contrary to the POSIX requirements, that if
two (possibly different hard-links) names point to the same inode, then
rename() is a no-op rather than removing one of the two names.  This
behavior is historical, even though it violates the principle of least
surprise, so the kernel can't really change it, and GNU coreutils 'mv'
has to go to great lengths to work around this shortcoming in the
syscall specification.

The new Linux renameat2() syscall would have to add a new RENAME_ flag
if we wanted any saner behavior (although there has also been a recent
report that one of the BSD's wrote a broken rename() syscall that
behaves sanely by default).  But until someone implements that, and we
can rely on it, then you must assume that "conftest.f" still exists
after this no-op call.

> 
> Step 2:
>     unlink ("conftest.f1")
> 
> Now I would expect confest.f1 to not exist after this.

Correct.

> 
> Step 3 is what confuses me.
> 
>    rename("conftest.f", "conftest.f") which is expected to work.
> 
> How can this succeed if "conftest.f" was removed in step 1?

Because it wasn't removed in step 1.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature