[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev anchor->FileCache (was: patch 8 - reusing temp files)
From: |
Henry Nelson |
Subject: |
Re: lynx-dev anchor->FileCache (was: patch 8 - reusing temp files) |
Date: |
Tue, 6 Jul 1999 19:36:57 +0900 (JST) |
> Yes, that's true. Note that they don't always survive until the end of
> the session (at leat they shouldn't - I haven't tested it for this
> specific situation, a compressed file of a type that is mapped to
> an external viewer). They should be cleaned up when the corresponding
> HTParentAnchor structure gets removed from memory (which is a kind
Okay, I'll look at it more from this perspective. It _seemed_ to me
that the files were hanging around until the end of the session, but
then they were very short test sessions.
> For one of them, 'D'ownload, the temp file needs to be kept around
> for as long as possible, so that the file is available for (possibly
> several) actions from the Download Options menu.
I had always thought that the file was erased when you push u)p to go
back to what you were looking at before pushing d)ownload.
> 2. The files that are passed to external viewers are kept around after
> the viewer command has been invoked and returned, because the viewer
> command may invoke the real viewer in the background. This makes
> sense especially for image viewers under X, or for audio players.
> Lynx cannot know when the viewer is completely done with the file,
> so it keeps it around.
>
> But there is a better solution than changing the lynx code IMO: just
> make the 'rm' part of the viewer you invoke. A wrapper script around
> 'most', that first calls 'most' and then 'rm', should do fine. Lynx
This is THE answer! (On both accounts. You're a genius.)
> There is the different case of compressed (remote) HTML and text/plain
> documents that lynx displays internally, for those temporary copies
> are alos kept around although there doesn't seem to be a good reason
> for it (unless lynx were changed to re-use those files upon re-loading).
> But you don't seem to be talking about that case.
I never remember seeing a temp file when pulling a compressed file off
of a web server. Is that because I have Lynx linked to libz, or is the
treatment of temp files the same whether Lynx does the decompression or
a helper app does? Guess I better go back and do some more study.
> (anchor->FileCache is completely separate, as far as I have seen, from the
> SOURCE_CACHE:FILE temporary cache file. The two mechanisms don't know
> about each other. It also seems that SOURCE_CACHE doesn't apply to
Well I better not get into this because my opinions, being opinions as
they are, are not overly popular :) (Now that the campus finally got
a dedicated caching proxy [12GB, super-fast scsi], I don't even have
the right to express an opinion anyway, I guess.)
As always, thank you very much for the help and hints.
__Henry