On Mon, Oct 11, 1999 at 11:04:44PM -0700, Jay Cox <jaycox@xxxxxxxxxxxxx> 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 +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
