On Mon, Oct 11, 1999 at 11:04:44PM -0700, Jay Cox <[EMAIL PROTECTED]> 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.

Under what circumstances will this happen? As soon as the user exits or
kills a runaway gimp the soace will be gone, so no space will be wasted.

> 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...

double segfaults are not rare.

> I think the issue really boils down to which we think is worse:  Completely
> invisible, but guaranteed temporary files, or visible files which (hopefully only
> rarely) get left around when there is a crash.

Well, I don't really see a reason why gimp has to manage its temporary
space unlike ANY other programs do - iso c explicity supports this kind of
temporary file management.

I really don't get it why we risk leaving around these files (on unix)?

> > 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.

I did. But its quite rare and I would be surpriused if anybody could produce
this case.

> I don't think we catch all of the possible signals curently, so we should be able
> to make it able to catch more crashes than it does now.

Why not just fix the problem at its root?

> > (tmpfile or unlink is the only reliable solution so far)
> It is not portable to assume that TMPDIR will control the location of a file
> created by tmpfile, so I would count it out as a solution.

We can roll our own tmpfile easily. I think that would be more portable
than trying to catch each and every signal.

> the file it would be extremly difficult for even an experienced operator to
> figure out why her disk was full.  An inexperienced operator would probably just
> assume it was an OS bug and reboot the machine.

Well, bugs are often difficult to diagnose.

> If we add the unlink call to the signal handlers and there is still a problem
> with swap files being left around, we could fairly easily (nearly) guarantee that
> any previous swapfiles left around by gimp running on the same host under the
> same user are deleted the next time gimp is run. (embed the user name, IP
> address, and process number at the top of the swap file)

Thats something I could go with -- my main concern are the 300mb swap
files I have to delete every month.

> uniquness. (mkstemp is a BSDism, is it portable?)

Portable to BSD, yes ;) Another thing a tmpfile replacement (if necessary)
would solve.

      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       [EMAIL PROTECTED]      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |

Reply via email to