Path: utzoo!utstat!news-server.csri.toronto.edu!math.lsa.umich.edu!zaphod.mps.ohio-state.edu!usc!snorkelwacker!ira.uka.de!smurf!urlichs
From: urlichs@smurf.sub.org (Matthias Urlichs)
Newsgroups: news.software.b
Subject: Re: trn bugs
Message-ID: <y6_]e2.+r6@smurf.sub.org>
Date: 20 Aug 90 16:05:18 GMT
References: <1990Aug10.045538.11435@mlb.semi.harris.com> <347@stephsf.stephsf.com> <9S&%XL#@rpi.edu>
Organization: University of Karlsruhe, FRG
Lines: 48

In news.software.b, article <9S&%XL#@rpi.edu>,
  tale@turing.cs.rpi.edu (David C Lawrence) writes:
<    From: wengland@stephsf.stephsf.com (Bill England)
< 
<    The thread files suffix a .th onto the file corresponding to the
<    newsgroup.  When a newsgroup has a name that is two long for the
<    filesystem mthreads can not build a thread file for it.
< [...]  you could work it now by letting trn keep its
< databases in the spool directory of each group as a .threads file.

Or you could put the "th" extension in front of the newsgroup name instead of
after. Or you can capitalize the name. Or...

But I hate to put anything other than raw articles onto my News disks.
They don't even have a lost+found directory -- what for? ;-)

< Another possibility, and one that can save lots of inodes too, is just
< to put it all in a flat filesystem. 

Lots of inodes? The 700 newsgroups at this site consume 700 for the trheads
files and another 170 for the directories (find this by "du /news/threads |
 wc -l"), so I suppose this doesn't matter.
On the other hand, I hate directories with 700+ files in them.

< [hashing newsgroups names into 14 characters]
You could use their position in the active file.
(Hashing is a bad idea because there may be collisions. What would you do?)

If the active file gets mangled/sorted/whatever, rename the database files.
(You did store the real newsgroup name in there, did you? ;-)

< Incidentally, in another article Mark Moraes, flat out said what I was
< implying before (I know, why bother implying when you can say it flat
< out) -- it would be really great if some sort of common database,
< maintained by a single daemon, could be used for these newsreaders.

Correct. It'd also be great if the news unspooler could maintain that database
instead of relying on a separate demon. (In that case, it would make sense to
have a common database for all news groups. Opening a database file,
searching for the position to enter the information, writing it, updating the
database's pointers, and closing the database, might be prohibitive if you'd
have to do it for each article. C News is very fast, and it should stay that
way.)


-- 
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(Voice)/621227(PEP)