Date: Wed, 13 Oct 1999 00:43:07 +0200
From: Marc Lehmann <[EMAIL PROTECTED]>
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
ften completely unaware of them.
>
> The devel branch has had code for toasting stale swap files on startup
> since Feb.
Is it working? I nuked at least 10 fi
On Mon, Oct 11, 1999 at 11:57:34PM +0200, David Monniaux <[EMAIL PROTECTED]> wrote:
> Under Linux at least, tmpfile() simply does an unlink() after opening the
> file. :-)
However, unlink is not available on mos tplatforms. tmpfile is available
on _every_ platform that supports C.
> The problem
ienced 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) guarante
On Tue, Oct 12, 1999 at 07:34:03AM -0400, Robert L Krawitz wrote:
>
> Yes, but it has other consequences that are not so benign, like being
> unable to find the file that's consuming a lot of disk space. Perhaps
> an alternative would be to mmap() the swap file? This would (I think)
> at least
t;[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
<[EMAIL PROTECTED]>
Date: 12 October 1999 05:34
Subject: Re: swap files
>
>The following is not a real solution, but it I think it would make the user
>understand the necessary internals better:
>
>Add a second dialog to the "User In
The following is not a real solution, but it I think it would make the user
understand the necessary internals better:
Add a second dialog to the "User Installation" process that explains the user
Gimp's way of handling memory and allows him to choose the size of the
tile-cache-size and the lo
Date: Tue, 12 Oct 1999 07:19:20 +0100 (BST)
From: Nick Lamb <[EMAIL PROTECTED]>
Almost every Gimp user I've met has one or more dead gimpswap files in
their home directory, and they're often completely unaware of them.
Fixing that in Gimp 1.2 would be really great, and if NFS is
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 m
On Tue, Oct 12, 1999 at 07:19:20AM +0100, Nick Lamb wrote:
> Almost every Gimp user I've met has one or more dead gimpswap files in
> their home directory, and they're often completely unaware of them.
The devel branch has had code for toasting stale swap files on startup
sinc
're hacking Gimp, but VERY VERY annoying
if you don't know the difference between an EIP and your elbow. It should
be off by default in even numbered tarballs.
> > I think it's ok to leave it as is in the developers version. In the
> > release, however, we should n
Almost every Gimp user I've met has one or more dead gimpswap files in
their home directory, and they're often completely unaware of them.
Fixing that in Gimp 1.2 would be really great, and if NFS is a problem
for the less than 5% of Gimp users stuck with gimpswap on NFS, then I
guess (unlink-on
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 aro
On Mon, 11 Oct 1999, Marc Lehmann wrote:
> 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).
Under Linux at least, tmpfile() simply does an unlink() after opening the
file. :-)
Simply touch the swapfile every 60 seconds. Any swap files that have
not had their time updated within the last 120 seconds get removed.
In the unlikely (but still possible) event that a swapfile is removed
before its time, due say to a nfs network outage, you simply find
youself in the
l 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 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 ar
On Mon, Oct 11, 1999 at 09:34:50AM +0100, Nick Lamb <[EMAIL PROTECTED]> wrote:
> On Sun, 10 Oct 1999, Federico Mena Quintero wrote:
>
> > lseek() returns the offset to which you seeked, so lseek (swap_fd, 0,
> > SEEK_END) will give you its size.
>
> I think this will just give you the LENGTH of
Marc Lehmann writes:
> 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
At least on Win32, and probably on OS/2, too, it is possible to open a
file so that it will be automatically deleted after closing. T
> I think this will just give you the LENGTH of the file? So, I don't
> know if it matters, but ISTR that Gimp uses files with holes, and
> therefore LENGTH != SIZE.
Oh, I didn't know this.
In any case, the program *does* know (or should) know the number of
tiles that it can have (tile cache
wap 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
On Sun, 10 Oct 1999, Federico Mena Quintero wrote:
> lseek() returns the offset to which you seeked, so lseek (swap_fd, 0,
> SEEK_END) will give you its size.
I think this will just give you the LENGTH of the file? So, I don't
know if it matters, but ISTR that Gimp uses files with holes, and
the
> 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.
> I think unlinking the swap files in the
y bad idea anyway) it might
go away (physically) on the server when gimp does not access it for
extended periods (>10 minutes).
However, any other solution (doing it in the signal handler) is extremely
annyoing (leaves too many swap files around).
In any case, why not use tmpfile or a similar
On Sat, 09 Oct 1999, Adrian Likins wrote:
> If I recall correctly, this has been suggested a few times
>and made it into released versions of gimp at least once, only to be removed
>later for reasons I do not recall. Seems like some sort of portability issues
>perhaps, but its been a long ti
's swap file.
>
I don't understand: can't you fstat your file handlers to compute used
space ?
> I think unlinking the swap files in the signal handler that is called when we
> crash would solve this problem. The cases where this will not work should be
> rare enough
David Monniaux wrote:
>
> Hi all,
>
> Many people around here complain that Gimp leaves enormous swap files when
> crashing. It is especially a pain since they are in a "hidden"
> subdirectory.
>
> Would it be possible to have Gimp unlink() the files after op
On Sat, Oct 09, 1999 at 01:29:59PM +0200, David Monniaux wrote:
> Hi all,
>
> Many people around here complain that Gimp leaves enormous swap files when
> crashing. It is especially a pain since they are in a "hidden"
> subdirectory.
>
> Would it be possible
Hi all,
Many people around here complain that Gimp leaves enormous swap files when
crashing. It is especially a pain since they are in a "hidden"
subdirectory.
Would it be possible to have Gimp unlink() the files after opening them?
I explain: if we use swap files as follow: open t
28 matches
Mail list logo
