On Sun, 10 Oct 1999, Federico Mena Quintero <[EMAIL PROTECTED]> wrote:
> [quoting Jay Cox]
> > If we unlink the swap file after opening it then we have no way of
> > knowing how much space gimp is using for it's swap file.
>
> lseek() returns the offset to which you seeked, so lseek (swap_fd, 0,
> SEEK_END) will give you its size.
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.
On Mon, 11 Oct 1999, Marc Lehmann <[EMAIL PROTECTED]> wrote:
> a) unlink might not succeed on non-unix-systems. cure: ignore the error from
> unlink and try to unlink it again after closing the file
This means in any case, we have to add some code that deletes the file
when a signal handler is called (close and unlink in case of a crash).
So if we have to do this in a signal handler anyway, why would we also
do it just after opening the file?
> b) if the swap file is on nfs (extremely bad idea anyway) it might
> go away (physically) on the server when gimp does not access it for
> extended periods (>10 minutes).
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).
> However, any other solution (doing it in the signal handler) is extremely
> annyoing (leaves too many swap files around).
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).
> In any case, why not use tmpfile or a similar function to create it? that
> function will do exactly what is required and will work on all systems (as
> good as it can).
The problem with tmpfile() is that it is not as easy for the user to
predict or change the location of the swap file. This function calls
tmpnam() which relies on TMPDIR for the location of the file. But in
some cases, the user might want to store the huge Gimp swap file on a
(slow but large) NFS-mounted partition instead of a (fast but small)
local disk, while all other applications would keep their reasonably
small temporary files on a local /tmp disk.
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.
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), but it has more advantages than the other solutions (or at
least less disadvantages).
-Raphael
