Date: Mon, 11 Oct 1999 23:04:44 -0700 From: Jay Cox <jaycox@xxxxxxxxxxxxx> Marc Lehmann wrote: > > A normal user has nothing to do with the swap file, except that he will > find that his disk is full and many hours later he might even find the > reason.... It will be much more difficult for the user to find the cause if we unlink the file as soon as we create it. The normal programs used to find wasted space like "du" and "find" will not be able to locate the unlinked gimp swap file. This would be a bad thing, particularly on multiuser systems. Or (again, particularly on a multiuser system) the system administrator. > Because it works. Doing it in the signal handler doesn't. If the gimp > doesn't crash there is no problem. If it does crash the signal handler > often isn't called at all. I can't remember the last time gimp crashed on me without the signal handler being called. I have had it hit infinite loops though... The most common infinite loop I've seen, in fact, is that when I run the Gimp in the background (I often run it as (gimp&) so it doesn't become a background task I might accidentally kill) and it hits the signal handler, it goes into an infinite loop asking me to tell it what to do (continue, dump core, debug, or whatever). It shouldn't try more than a couple of times, and if it can't get any input from the user, die appropriately. > > In some cases, you do not have the choice. On several machines that I > > use at work, I have to put the swap file on NFS because all writable > > partitions are mounted over NFS (except for /tmp but it is too small). > > unlink also works over nfs. I think someone else posted in this thread a way in which unlink could actually get rid of the file before the file is closed if the file resides on an NFS volume. What usually happens is that on the server there's something spawned by cron that periodically goes around and looks for files named .NFS* which it nukes if they're too old (usually measured in days). It's possible that other NFS servers do things differently. Clients that do anything like this are completely broken. In any event, a kernel crash on the client will result in these files not being removed. The handling of removed-but-still-open files is not one of NFS's strong points. -- Robert Krawitz <rlk@xxxxxxxxxxxx> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lpf@xxxxxxxxxxxx "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
