Re: [leafnode-list] [ANNOUNCE] First Leafnode-2.0 beta version

[krasel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx (Cornelius Krasel)]

Joerg Dietrich wrote:
> On Fri, Oct 27, 2000 at 05:53:09PM +0200, Cornelius Krasel wrote:
> > In getxover(), one of the first things is to read the overview file
> > (which is already sorted) into memory and parse it (i.e. a sorted
> > xoverinfo array is created). Then, these data are compared with the
> > files on disk, in case some files have been added after construction
> > of the .overview file. In that part occurs the code snippet quoted
> 
> Isn't the overview we read from disk overwritten by
> 
> memset( xoverinfo, 0, sizeof(struct xoverinfo) * (xcount+current+1) );
> 
> which occurs earlier?

No. The overview file is read into a buffer called "overview" and
the number of CRs in this buffer counted. Then the memory for
"xoverinfo" is allocated and cleared (by the memset() command above).
Only then "overview" is parsed and "xoverinfo" filled by its
parsed contents.

> > by Joerg. The directory is read, and for each directory entry the
> > code above tests whether it already exists in the xoverinfo array.
> > In that case, the "exists"-flag is set to 1.
> 
> You forgot the rest :-) If the article is new, i.e. not present
> in the .overview on disk, the new overview line is generated and
> added to the xoverview array. From now on the array is unsorted
> and calling findxover() is pointless.

Are you sure? findxover() searches only through "xcount" members
of the array; if there are additional entries behind that, these
are not considered. xcount is only changed at the very end of the
function.

> I stumbled over it in an extreme case: de.newusers.info is a
> group with weekly information postings that supersede their
> earlier incarnation. Once a week when they're all posted the 
> overview file contains 15 lines of articles that don't exist
> anymore, and de/newusers/info/ contains 15 articles that are not
> in the old .overview file. Lets say we've been through the
> 
> while ( (de = readdir(d)) != NULL ) {
> 
> loop 10 times. Then xoverinfo[] contains nothing but 10 unsorted
> entries.

No, not at that stage. At that stage xoverinfo[] contains the
15 old entries which have just been superseded (because the
overview file hasn't been updated yet) AND after that the 15
new unsorted entries (at least that is what *should* happen :-)
- I don't have the opportunity to check that at the moment). The
old entries are only thrown out in writexover() because there, only
entries with "exists = 1" are written to disk.

(Actually, while writing this it occurs to me that the old .overview
 entries are not written to disk but they probably still exist in
 memory after getxover() has been called. This is definitely a bug
 and explains some odd behaviour that I have observed with tin sometimes.
 This could probably be fixed by adjusting the _compxover function.)

I understood the helpfindxover() patch now, BTW. Thanks :-)

--Cornelius.

-- 
/* Cornelius Krasel, U Wuerzburg, Dept. of Pharmacology, Versbacher Str. 9 */
/* D-97078 Wuerzburg, Germany   email: phak004@xxxxxxxxxxxxxxxxxxxxxx  SP4 */
/* "Science is the game we play with God to find out what His rules are."  */

-- 
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx -- mailing list for leafnode
To unsubscribe, send mail with "unsubscribe" in the subject to the list