On Wed, Sep 15, 2004 at 04:54:29PM -0400, Andrew Schretter wrote:
>
> On local disk runs, TEMP/BAR still exists (I don't know why though). On NFS
> runs, it does not exists. This breaks connectathon's test.
Client: 2.6.8.1, server: 2.4.27 (serving ext3)
/proc/mounts: rw,nosuid,nodev,v3,rsize=8192,wsize=8192,hard,udp,lock
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
output:
ls: FOO: No such file or directory
-rw-r--r-- 1 fvm sec 3 Sep 16 00:21 TEMP/BAR
(CC'ed to lkml)
--
Frank
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.