Re: vfs bug. was: Re: [NFS] 2.6.8.1 kernel NFS client connectathon failure

[viro@parcelfarce.linux.theplanet.co.uk]

On Thu, Sep 16, 2004 at 12:23:58AM +0200, Frank van Maarseveen wrote:
> Behavior I see is identical to that on a local (ext3) fs on 2.6.8.1 and
> also on local ext3 on 2.4.27, namely that TEMP/BAR still exists. This
> looks like a long standing kernel bug since the rename(2) seems to
> succeed:
> 
> (snippet from strace):
> write(3, "...", 3)                      = 3
> close(3)                                = 0
> link("FOO", "TEMP/BAR")                 = 0
> rename("TEMP/BAR", "FOO")               = 0
> unlink("FOO")                           = 0

Behaviour is REQUIRED by POSIX and SuS.

<quote>
     If the old argument and the new argument both refer to, and both
     link to the same existing file, rename() returns successfully and
     performs no other action.
</quote>

So what you get is
	* after link(2) success - FOO and TEMP/BAR being links to the same
file.
	* after rename(2) (required) success - same as before
	* after unlink(2) - FOO is removed, TEMP/BAR remains.