Path: utzoo!utstat!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!uunet!drivax!davison
From: davison@dri.com (Wayne Davison)
Newsgroups: news.software.b
Subject: Re: trn bugs
Message-ID: <7T9NGS7@drivax.UUCP>
Date: 20 Aug 90 18:01:40 GMT
References: <1990Aug10.045538.11435@mlb.semi.harris.com> <347@stephsf.stephsf.com> <9S&%XL#@rpi.edu>
Sender: news@drivax.UUCP (news admin)
Followup-To: news.software.b
Organization: Digital Research, Monterey CA
Lines: 45

David C Lawrence (tale@turing.cs.rpi.edu) wrote:
> [Some good discussion on solutions to adding the .th suffix on long thread
> filenames when your operating systems only supports 14-character names.]

I'll just add some details to what David said:  putting the .thread file in
each group's spool directory is the most portable option (if you've got the
space on the spool partition).  If you need a separate thread hierarchy,
you can make a simple change in common.h and rebuild the database; change:

	#define SUFFIX ".th"
to:
	#define SUFFIX "/thread"

to tell mthreads to create an extra directory per group to put the thread
file in.  This will eat up more space, but you won't have to worry about
long group names.

> Another possibility, and one that can save lots of inodes too, is just
> to put it all in a flat filesystem.  It shouldn't be terribly
> difficult to come up with a quick algorithm that could hash a news
> group name into fourteen character names.  I'd even be willing to do
> it if Wayne wants.

I'd certainly support such a solution, as long as there was some good way
to avoid duplicate hash names.

> Kim Storm uses the flat filesystem approach for nn.  Well, almost
> flat.  He has a GROUPS file in the database directory and a DATA
> subdirectory which holds the group data in two seperate files for each
> group.  The identifying portion of the file name is its line number,
> zero based, in the GROUPS file.

It's even less flat now -- the database has been further divided into 100-group
subdirectories to avoid creating a directory with 1200 files in it (due to the
slow file searching that results from having a lot of files around).

> it would be really great if some sort of common database,
> maintained by a single daemon, could be used for these newsreaders.

Yes, it would be nice.  Kim Storm and I are keeping in touch on this
subject, but it isn't too high on the priorities right now.
-- 
 \  /| / /|\/ /| /(_)     Wayne Davison
(_)/ |/ /\|/ / |/  \      davison@dri.com
   (W   A  Y   N   e)     ...!uunet!drivax!davison