lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev 2.8.3dev.2 patch 8 - reusing temp files


From: Henry Nelson
Subject: Re: lynx-dev 2.8.3dev.2 patch 8 - reusing temp files
Date: Tue, 29 Jun 1999 14:10:25 +0900 (JST)

> page, after being created once, would always be the same file
> (/tmp/L7013-4TMP.html or whatever).  This changed in connection with

This message is a little off topic and deals only with temp files
created in the course of handling files matching "if (skip_loadfile) {",
around line 273 in src/HTFWriter.c.  I've already posted my interim
solution, which is simply to remove the temp file when the viewer exits:
                            FREE(me->remove_command);
                        }
+                       remove(me->anchor->FileCache);
Mostly I'm asking for advice/opinions; no need to do anything if there
is no interest.  The simple removal works fine, but it could be "cleaner."

The problem, from my point of view (rather limited disk space, even more
limited memory, yet wanting any number of users to be able to view large,
>1MB files), is twofold: 1) Lynx accumulates temporary files until it
exits, and 2) despite having a file decompressed on disk, Lynx goes ahead
and decompresses it again.  My focus in this message is '2)'.

For a concrete example, let's say I hit a link which points to a file
with two levels of extensions, each mapped in .mime.types and .mailcap.
The outside one, "gz", is for passing to gunzip, and the inside one,
"arc", is for passing to the viewer most.  On disk I get a temp file:
-rw-------   1 user     1333410 Jun 29 12:44 L3394-1TMP.arc
I quit the viewer, and the temp file remains as is:
-rw-------   1 user     1333410 Jun 29 12:44 L3394-1TMP.arc
I hit the link again, and Lynx passes the gzipped stream to gunzip, and:
-rw-------   1 user     1333410 Jun 29 12:45 L3394-2TMP.arc
"L3394-1TMP.arc" is gone, so Lynx has either removed it, or has renamed
it to "L3394-2TMP.arc" and written the unzipped stream over it.
If I open another file, I get a unique temp file being created:
-rw-------   1 user     1333410 Jun 29 12:45 L3394-2TMP.arc
-rw-------   1 user     1845464 Jun 29 12:46 L3394-3TMP.arc

This means that Lynx knows that it has already unzipped a certain
file and has a temporary copy of it available (otherwise it wouldn't
know when it can delete a file only to make another exact copy with a
different name).  A "smart" Lynx would skip the decompression step
and pass the copy it already has directly to the viewer again, or not
even bother to remember what it has since it is going to junk it
immediately after it has used it.  The latter is what I was thinking
of doing, but I wonder if it needs to remember what the file was
for some kind of recovery mechanism.

__Henry

reply via email to

[Prev in Thread] Current Thread [Next in Thread]