[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