Date: Mon, 11 Oct 1999 23:04:44 -0700
From: Jay Cox <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
