In article <35kaauF4npmfmU1@individual.net>,
Thomas Rademacher wrote:
>Hello,
>
>on an AIX 5.1 I make many file oparations in a directory 'mydir' with a
>python script.
>At the end of the script I want to remove all files in 'mydir' with the
>python function os.remove().
>In some runs I can not remove all files, because a file .nfsXXXX exists.
>
>Why does a .nfsXXXX file exist?
>How can I remove this file?
>
>Thank you for your hints, Thomas
>

The .nfsXXXX file is created by the NFS client. This is done in order
to preserve the UNIX file system semantics which dictate that a file's
contents are available as long as at least one reference to the file
exists in the system.

Here is how this works:

- The end of your script - which is running on the client for reasons
we shall see immediately - removes the last file system reference to
the file (i.e., the last - and in most cases only - directory entry
which points to the file).

- However, also on the client machine, a *process* still has the same
file opened.

- Since NFS is a stateless protocol (or at least nearly so, with the
only state shared between client and server being the NFS cookies),
the server has no information about how many files of it are opened
on remote machines.

- Hence, if something (even a client) removes the last file system
reference (i.e., directory entry) to a file on the server, *and*
no process on the server itself has the file open, the server will
free all storage associated with the file, thus losing the file
contents.

- But, as said above, a process on the client machine still has the
file in question open. Losing any possibility of accessing this
file would therefore break UNIX file access semantics, at least from
this client machine's point of view.

- Therefore, in order to force the server to keep the file's contents,
the *client* tells the server that instead of really deleting the
file, it should rather rename it to a .nfsXXXX file (UNIX's famous
"sillyrename" function). This way, the "real"/"old" name (and file
system reference) of the file is deleted, but the file's contents
are still available (because the server has to keep them for the
.nfsXXXX directory entry), thereby fulfilling the UNIX file system
semantics.

- Later, when the (last) process on the client which holds the (last)
reference to the file closes this file, the *client* will silently
delete the .nfsXXXX file.

The rename and actual deletion are all handled by the client OS, which
is the only entity holding the full state information.

All of this has the following implications:

- Using scripts on the *same* client that has the file in question
open to delete the .nfsXXXX file will just result in another file
with a new number being generated.

- You just need to wait until all processes on the *same* client which
have the file open, close it, and the .nfsXXXX file will vanish
"automagically".

- If the client crashes before the "automagic" remove happens, .nfsXXXX
files will accumulate on the server.

- Let us call the client machine with the process holding the open
reference to the file "machine A". If a process on either the NFS
server or any other NFS client machine besides "machine A" deletes
the file, then "machine A"'s OS clearly has no chance of doing its
automagic sillyrename thingie, and the file will be gone for good.
In this case, any further operations the process on "machine A" tries
to do on this file will fail with "stale file handle" (ESTALE in errno.h).

Which leads to the conclusion that NFS probably contributed quite a bit
to what the http://www.simson.net/ref/ugh.pdf is ranting about. :-)

Regards,

Martin
--
Martin Birgmeier

Vienna
Austria

Martin Birgmeier wrote:

> Which leads to the conclusion that NFS probably contributed quite a
bit
> to what the http://www.simson.net/ref/ugh.pdf is ranting about. :-)

There's an SMB client on Linux. Go use that. :-)