home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / question / 13281 < prev    next >
Encoding:
Internet Message Format  |  1992-11-12  |  3.2 KB
  1. Path: sparky!uunet!mcsun!Germany.EU.net!nixpbe!uranium!uranium!not-for-mail
  2. From: Josef Moellers <mollers.pad@sni.de>
  3. Newsgroups: comp.unix.questions
  4. Subject: Re: 2nd time:How to remove files?
  5. Date: 12 Nov 1992 16:46:48 +0100
  6. Organization: Siemens Nixdorf Informationssysteme AG, Paderborn, Germany
  7. Lines: 53
  8. Sender: josef@uranium.sto.pdb.sni.de
  9. Message-ID: <1dtu98INNkqq@uranium.sto.pdb.sni.de>
  10. References: <Nov.11.13.41.20.1992.909@skynyrd.rutgers.edu>
  11. NNTP-Posting-Host: uranium.sto.pdb.sni.de
  12. Keywords: remove, unix, corefiles
  13.  
  14. In <Nov.11.13.41.20.1992.909@skynyrd.rutgers.edu> puchalek@skynyrd.rutgers.edu (michael) writes:
  15.  
  16.  
  17. >    I posted this article in comp.unix.questions with a narrow
  18. >distribution, so I am reposting with a wider range. If you see it
  19. >twice, sorry.
  20.  
  21. >I keep getting files added to my working directory such as 'xerrors'
  22. >and '.nfs***'. If I put a line in my .login that says 'rm xerrors', a
  23. >'xerrors:no such file' message appears every time I log in. If I leave
  24. >the 'rm xerrors' line out of my .login, the 'xerrors' file starts to
  25. >show up in my root directory.  The '.nfs***' files appear whenever I
  26. >am working in the text editor, emacs in this case. I have uncommented 
  27. >the line 'limit coredumpsize 0' in my .login.  Any suggestions? If it is 
  28. >more convenient to email, that's fine.
  29.  
  30. I can't say anything about "xerrors", but as far as ".nfs***" is
  31. concerned:
  32. NFS is a stateless system. That means that neither the server, nor the
  33. client can assume anything about the state of the other side.
  34.  
  35. One of the things the server is not allowed to know is the idea of "open
  36. files" on the client's side. Therefore, whenever the client opens a file
  37. on an NFS-mounted file system, and subsequently unlinks the file
  38. _before_ closing it, the client cannot completely remove the entry from
  39. the directory, as this might be the last reference to the file and the
  40. server (who doesn't know the file is still open on the client's side)
  41. will remove the file, freeing all disk blocks that are/were allocated to
  42. the file. UNIX's notion is, however, that the file remains on disk
  43. _until the file is closed for the last time_, i.e. until either the
  44. process closes the file or the process dies (closing the file
  45. implicitly).
  46. In order to allow the file to remain open and still "free" the directory
  47. entry (or at least allow the file's name to be re-used), the NFS client
  48. silently renames the file to ".nfs<number>", where <number> is generated
  49. automagically. When the process closes the file, the NFS client software
  50. will detect this and send an "unlink" command to the server which will
  51. then _really_ remove the file and free up all disk space.
  52.  
  53. This will also pop up when You "open" the last file in a directory, then
  54. "unlink" it and then try to "rmdir" the directory it is in.
  55. Under S5 or UFS file systems, this works OK: the directory is gone.
  56. Under NFS, You'll get a "directory not empty" error, and when You look:
  57. voila! It's empty! B-{)
  58.  
  59. Does this make sense to You?
  60.  
  61. I assume that "xerrors" is created by some X-windows product and removed
  62. whenever the product terminates. So, why worry?
  63. -- 
  64. | Josef Moellers        | c/o Siemens Nixdorf Informationssysteme AG  |
  65. |  USA: mollers.pad@sni-usa.com    | Abt. STO-XS 113       | Riemekestrasse   |
  66. | !USA: mollers.pad@sni.de    | Phone: (+49) 5251 835124 | D-4790 Paderborn |
  67.