On Wed, 2 Aug 2000, Thomas E. Dickey wrote:
> On Wed, 2 Aug 2000, Klaus Weide wrote:
> > On Mon, 24 Jul 2000 [EMAIL PROTECTED] wrote:
> > > Furthermore, Lynx's use of cp(1) rather than mv(1) allows the user
> > > to save a file to multiple destinations, if desired, without
> > > re-fetching from the net.
> >
> > That is the major reason why lynx uses cp, as I understand it.
>
> actually I had a different impression - much of the odd features in lynx
> originated on VMS; in this case there are some odd problems copying
> files that are better left to the system's copy utility.
>
> But agreed - the main reason for using cp rather than trying to rename
> it is to allow subsequent use.
Actually, it's the case _on VMS only_ that lynx does _not_ always copy -
it tries a rename first() and falls back to copy if the rename fails.
I see no reason why the same logic _couldn't_ be implemented for UNIX
etc., but I do prefer the current behavior (even though I *do* frequently
run out of tmp space)!.
> It would be nice to know what files
> are currently in-use though - the history page doesn't quite do that.
Not sure what you mean - how you define "currently in-use".
Actually only the one temp file downloaded most recently is still usable
on the "Download Options" page, but others may hang around for some
time longer (until anchor->FileCache gets removed). That makes sence
IMO because someone may have started running a DOWNLOADER command
on one of the previous download files that operates in the background.
Klaus
; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to [EMAIL PROTECTED]
