294 NFS One of the reason that NFS silently corrupts files is that, by default, NFS is delivered with UDP checksum error-detection systems turned off. Makes sense, doesn’t it? After all, calculating checksums takes a long time, and the net is usually reliable. At least, that was the state-of-the-art back in 1984 and 1985, when these decisions were made. NFS is supposed to know the difference between files and directories. Unfortunately, different versions of NFS interact with each other in strange ways and, occasionally, produce inexplicable results. Date: Tue, 15 Jan 91 14:38:00 EST From: Judy Anderson yduj@lucid.com To: UNIX-HATERS Subject: Unix / NFS does it again... boston-harbor% rmdir foo rmdir: foo: Not a directory boston-harbor% rm foo rm: foo is a directory Eek? How did I do this??? Thusly: boston-harbor% mkdir foo boston-harbor% cat foo I did get an error from cat that foo was a directory so it couldn’t out- put. However, due to the magic of NFS, it had deleted the directory and had created an empty file for my cat output. Of course, if the directory has FILES in it, they go to never-never land. Oops. This made my day so much more pleasant… Such a well-designed computer system. yduJ (Judy Anderson) yduJ@lucid.com 'yduJ' rhymes with 'fudge' Freeze Frame! NFS frequently stops your computer dead in its tracks. This freezing hap- pens under many different circumstances with many different versions of NFS. Sometimes it happens because file systems are hard-mounted and a

Not File System Specific? (Not Quite) 295 file server goes down. Why not soft-mount the server instead? Because if a server is soft-mounted, and it is too heavily loaded, it will start corrupting data due to problems with NFS’s write-back cache. Another way that NFS can also freeze your system is with certain programs that expect to be able to use the Unix system call creat() with the POSIX- standard “exclusive-create” flag. GNU Emacs is one of these programs. Here is what happens when you try to mount the directory /usr/lib/emacs/ lock over NFS: Date: Wed, 18 Sep 1991 02:16:03 GMT From: meuer@roch.geom.umn.edu (Mark V. Meuer) Organization: Minnesota Supercomputer Institute Subject: Re: File find delay within Emacs on a NeXT To: help-gnu-emacs@prep.ai.mit.edu4 In article 1991Sep16.231808.9812@s1.msi.umn.edu meuer@roch.geom.umn.edu (Mark V. Meuer) writes: I have a NeXT with version 2.1 of the system. We have Emacs 18.55 running. (Please don’t tell me to upgrade to version 18.57 unless you can also supply a pointer to diffs or at least s- and m- files for the NeXT.) There are several machines in our network and we are using yellow pages. The problem is that whenever I try to find a file (either through “C-x C-f”, “emacs file” or through a client talking to the server) Emacs freezes completely for between 15 and 30 seconds. The file then loads and everything works fine. In about 1 in 10 times the file loads immediately with no delay at all. Several people sent me suggestions (thank you!), but the obnoxious delay was finally explained and corrected by Scott Bertilson, one of the really smart people who works here at the Center. For people who have had this problem, one quick hack to correct it is to make /usr/lib/emacs/lock be a symbolic link to /tmp. The full explanation follows. I was able to track down that there was a file called !!!SuperLock!!! in /usr/lib/emacs/lock, and when that file existed the delay would occur. When that file wasn’t there, neither was the delay (usually). 4Forwarded to UNIX-HATERS by Michael Tiemann.