templ@inf.ethz.ch (Josef Templ) (12/18/90)
Recently I discovered a problem with Sun's nfs implementation.
Let F be an "open" nfs file.
When removing F while it is still open
a temporary file named .nfsXXX is generated
and the inode is still accessible.
This works fine as long as unlink is used to
remove the file, but it does not work, if F is
deleted as a side effect of a rename system call.
rename("F1", "F") destroys the inode of F and leads
to error ESTALE (stale nfs handle) when accessing F
later on. The man pages for
rename state explicitely that "if to exists, then it
is removed first". But why is this remove different from
an unlink?
I consider this behavior to be an error because
it violates the assumption of transparent file access
via the network.
I would appreciate any comment on this problem.
Is it a known bug of nfs? Is it the same problem
for all nfs implementations. What is a clean way to
program around it.
Thanks in advance
Josef Templ, ETH Zurich