48

I have an application running (on RHEL5) that streams data onto an NFS share. Recently, I saw a lot of .nfsXXXX... (xxx being a hexadecimal number) appearing in its working directory, where the application writes hourly files and later moves them to a different filename.

What are these files? Is it an indication of something gone wrong? How to do further diagnose?

Nathan
  • 167
  • 7
nos
  • 2,418
  • 3
  • 21
  • 24

3 Answers3

39

Nothing is going wrong. This is your NFS client trying to maintain proper "delete on later close" unix behavior within its own operational abilities. This NFS behavior is known as "silly rename":

http://nfs.sourceforge.net/#faq_d2

NFSv4.1 will get away from this behavior with OPEN4_RESULT_PRESERVE_UNLINKED:

https://www.rfc-editor.org/rfc/rfc5661#section-18.16.

Community
  • 1
beans
  • 1,580
  • 13
  • 16
2

Adamo is correct. Make sure that your app is closing the files once it is done with them.

If you can't fix the app for whatever reason, you could create a cron job to regularly remove the files.

Cory J
  • 1,568
  • 5
  • 19
  • 28
  • 8
    That cron job would be useless. As long as the files are open, removing the .nfsxxxx files will just trigger new .nfsyyyy files popping out. – jlliagre Nov 19 '10 at 09:03
  • 2
    It's not useless because usually they get closed later but the file stays. – JOTN Feb 12 '11 at 14:08
0

Before deleting a file, make sure that the files I/O has been closed.

Most network file servers will generate hidden files such as .nfsXXXXXX and/or .smbXXXXXX. Those hidden files will be deleted after the process, which did not close the file i/o handler, exited.

bjoster
  • 4,805
  • 5
  • 25
  • 33
Max
  • 1