Re: lynx-dev Options, V.Links, random (was: patch 6 - UI Pages)

[Klaus Weide]

On Thu, 16 Dec 1999, T.E.Dickey wrote:
[kw:]
(btw. I used sequential-like rather than random-like example names - but
that does not affect the point I tried to demonstrate.)
> > You selected: 
> >  53. [2]Options Menu 
> >      file://localhost/tmp/L12845-320TMP.html 
> >  52. [3]Options Screen Help 
> >      
> > file://localhost/usr/local/lib/lynx_help/keystrokes/option_help.html.gz 
> >  51. [4]Options Menu 
> >      file://localhost/tmp/L12845-319TMP.html 

> > At this point, you can go back to #51: PREV_DOC twice. 
> > There are two cases that are normal: 
> > a) #51 is still in the cache of rendered docs.  So it gets displayed. 
> >    When it is shown, RELOAD will result in an error.  It should - the 
> >    file doesn't exist any more. 
> > b) #51 isn't cached any more.  "Returning" to it results in an error 
> >    message (and skipping it on the history stack). 
> > [ If you think that's *not* what should "normally" happen - well, see if 
> >   it does.  You could use REUSE_TEMPFILES to change behavior, but that 
> >   would then be a different case. ] 
> > The possibility of filename reuse opens up a third case, one that is 
> > clearly wrong: 
> 
> but my change limits rather than expands the set of filenames available for
> opening.

Yes - I didn't say that this latest patch causes the appearance of
case (c) - "the possibility of filename reuse" does.  This latest
patch just doesn't prevent it, in this case (although it does prevent
collisions in some other cases).

> > c) "Returning" to #51 results in loading and display of the wrong contents. 
> 
> but is this related to the random-sequence?  (I did not see anyplace where
> we use the actual sequence number anymore - it's done by filename).

Using a limited pool of names means that there is the possibility of
collision.  Creating names from this pool in pseudo-random fashion
means that, as soon as you have generated two filenames, there is some
chance that they are the same - and the more names you generate, the
hight the chance of collisions.

By contrast, for the previous implementation (as used for Unix-like
systems, at least): The size of the pool of names is nearly equivalent
to "unlimited", for practical purposes.  Additionally, cycling through
names in ordered fashion means that there is *zero* chance of generating
the same name twice until you have gone through all the pool once.

So yeah, I'd say the random-sequence, as used by you, "causes this",
as a practical possibility in realistic situations.

> If
> it's not related to the random-sequence, it would still be a bug which we
> should fix (but a different topic).

To elaborate on my previous sentence - the random-sequence "causes"
that the Lynx process (session) may stumble over its own feet (== create
a filename usage conflict among its own files).  OTOH, the fact that
Lynx can stumble at all (== be tricked into loading something when it's
supposedly loading something else) is a more general problem, of course.
That would be that "different topic".

To discuss that other topic briefly: yes, I see a chance here for an
outsider to confuse the Lynx user (and possbly some of the LYIsUIPage
checking logic).  I didn't see it earlier.  Have to think about it more...


> > > +#ifdef USE_RAND_TEMPNAME 
> > > +    /* If we really have 10000 files open, there's no point in 
> > > returning... */ 
> > > +    } while (FindTempfileByName(result) != 0); 
> >  
> > This is the important point.  You are checking ly_temp, but not whether 
> > any document points to that file, nor whether LYIsUIPage is true, nor 
> > whether any other kinds of pointers still exist to that filename or URL 
> > that might result in another attemt to access it, (nor whether the file 
> > really exists).  No, I don't suggest you add any such checks - I still 
> > suggest forget about the rand() in filenames... 
> 
> but I _am_ checking if Lynx has opened the file as a temporary file, and if
> Lynx has not explicitly discarded it.

Yes, it's just not enough to prevent *all* kinds of collisions, only
some.


   Klaus