Marc Lehmann wrote: > > On Mon, Oct 11, 1999 at 10:52:56AM +0200, Raphael Quinet <quinet@xxxxxxxxxx> wrote: > > This is fine from within the Gimp. But most of the time I want to > > monitor the size of the swap file from a shell window, while the Gimp > > is performing some memory- and CPU-intensive tasks on a large image. > > If we unlink the file after opening it, then the file may not be > > visible in a directory listing. I suppose that this depends on the OS > > and filesystem used. > > But this sounds as if this is debugging code for the developers debugging or > hacking the swap code. > > 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. > > So if we have to do this in a signal handler anyway, why would we also > > do it just after opening the file? > > 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... > I think it's ok to leave it as is in the developers version. In the > release, however, we should not leave (very large and very hidden!) swap > files around. 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. > > 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. > > Are you sure about that? I think that it is more likely that the Gimp > > crashes and calls the signal handler than to have a power failure > > (which has more serious effects than just leaving a swap file around). > > At leats during my owrk gimp either crashes silently or goes into an endless > loop. How do I know a signal handler is called? Also, a segfault is often > non-catchable (in practise, not in theory). > > > It could still be possible to use tmpfile() as long as we clear or > > override TMPDIR from inside the Gimp, but this is not a very elegant > > solution. > > But a very portable solution. And it also works. However, just doing > remove() after the open and ignoring errors might be good enough (the > win32 port where this is not possible already uses a different method to > make it reliable, or so I understood it). > > > I would prefer to have the file closed and unlinked in a signal > > handler. This is not a perfect solution (e.g. in case of power > > failure) > > ... and crashes. 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. > > but it has more advantages than the other solutions (or at least less > > disadvantages). > > Well, I admit people hacking the swap code wouldn't find it funny. But > adding an ifdef for these developers in the source sounds much better than > impairing every unlucky user. > > (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. In recall that recently there was a bug in the swap code that caused gimp to continuously grow the swap file even while it was not being used. If we unlink 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. 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) Jay Cox jaycox@xxxxxxxxxxxxx PS: the current method of determining the name of the swap file is not safe if the swap file is on a shared device. We should probably use mkstemp to guarantee uniquness. (mkstemp is a BSDism, is it portable?)
