BL> Doesn't it even check if the file is there?

 PE> Yes, that is why I ask people to send the file before the TIC,
 PE> to avoid aborted transfers. 

  Eh? If the file is not there, then the transfer *has* to abort. If
the file arrives without the TIC, yu'll end up with a file and nothing
will happen. Wouldn't it be better to send the TIC first? At least it
would abort automatically when it didn't find the file.

 PE> I was referring that there are (currently) two completely
 PE> separate programs. TIC to add the files to files.bbs, and
 PE> Downsort to create the fancy file list, with reference to
 PE> files.bbs and the directory. 

  Oh! I didn't realise that.

 BL> I don't think I'll be able to rebuild the FILES list in a
 BL> second... probably two or three if it needs a lot of changes.

 PE> This is part of your idea of doing it online. It doesn't need
 PE> to update the files list online, I can do that *after* every
 PE> call. Currently I am doing it once/day. 

  It's the same logic for me... except that if I can do it online I am
*sure* no one will call while it's truckin'. If it takes more than a
few seconds, you need a quiet time with no calls to do housekeeping.

 PE> Currently, downsort will compare files.bbs with the directory.
 PE> Any discrepancies turn into either "no description available"
 PE> or "archived". 

  Yair... I was going to actually delete entries if the file isn't
there, or zero length.

 BL> I thought about this... but what's the difference? I *have* to
 BL> read the file name and description from a file that is
 BL> constantly updated,

 PE> files.bbs is the one to trust. Not f711x934.txt.

  That's my point! What's the difference? One is derived from the
other, so if I do away with files.bbs then f711x934.txt is the same.

  But I've talked myself out of it. I can open and close a file in
50mS, so it will be faster if I split the files into sections. 24
files is only 1.2 seconds, addign one to the other... plus whatever it
takes to sort and rewrite SPECIALR.

  The idea I *really* like is to put specialr on the end, and just
revise and append the new one each time. I could do that in 0.2
seconds.

 BL> and if I can trust *that* not to degenerate then why not trust
 BL> it for the headers too?

 PE> There's no headers in files.bbs.

  So? Why not? It's just as easy to copy as to write a new one.

 BL> Using a separate header template adds another way to get
 BL> screwed up, if for instance you added a new section in FILES
 BL> but forgot to modify

 PE> I don't add a new section in files. I add a new section by
 PE> updating:

 PE> 1. Maximums control file and recompiling.

 PE> 2. Creating the directory.

 PE> 3. Adding it to the binkley list of directories you can FREQ
 PE> from.

  Does Binkley create files.bbs?

 PE> files.bbs, the directory itself, and the maximus control file
 PE> are as safe as you can get. I don't care if you want to replace
 PE> the maximus control file with some other file. 

  The Maximus control file lets you freq, but that's a separate
problem. This program lets you put files in, not take them out.

  The directory is the master. If the file ain't there it don't work. 
  What remains is the FILES list, and it has three parts: the pretty
headers, the file names/size/date, and the descriptions. As a minimum
we need a list that brings these three together, or we can store
them separately and duplicate, linking one or more parts.

  AFAIK, your existing system keeps names and descriptions in 24
separate files, plus the headers in another file linked to the names
of those files, plus files.bbs as a raw *sorted* file with "archived"
and where-did-it-go, and finally where it all comes together as
f711x934.txt. By simply logic, it is possible to eliminate everything
up to the final FILES list... and you *should*.

 PE> You are using "FILES list" in two contexts here. Refer to the
 PE> names we are used to here, files.bbs (standard in most places,
 PE> you will even find it on CDROMs) and f711x934.txt (my name for
 PE> the master files list). 

  To me FILES is f711x934.txt... the formatted pretty list I get when
I freq FILES. To me, if you want to modify it, just save a backup and
do it. Why buggerise around somewhere else? You only create ONE file,
so why do you need any more? Unless files.bbs is created by Bonkley or
something.

 PE> Yes, yatic has a configuration file where I specify this.
 PE> Actually it has a configuration program, but a configuration
 PE> file would be preferable (to me). 

  Yes... I think I prefer an ascii cfg file. Even in Telix, it's
easier to modify the file.

 BL> [Areas   number, directory, TIC name, list name]
 
 BL> 1,c:\rswipe,PCOOK,Paul's cooking list
 BL> 2,d:\Iforget,DOGGY,10000 X-rated dalmatians
 BL> 3,c:\rswipe,USLS,10000 totally useless files
 BL> 4,c:\bbsoft,ELLE,10000 tits
 BL> 5,c:\bbsoft
 BL> 20,c:\bbsoft,SPECIALR,Special Requests

 PE> You are repeating directories here, ie c:\bbssoft.  This is not
 PE> something you want to do. 

  I thought you might want to do that. If FILES is split up in
sections, you can read and sort those names, and share a directory
with another section. You could even put the same file name in
different sections. Or not. It's your choice.

  In my system, the only way you delete a line from the FILES list is
if the file does not exist in the directory to tell that section to to
look at.

 BL> [Points      point number, name, password, Area access allowed]
 
 BL> 1,Rod Speed,genius,1,2,3,20,25
 BL> 2,Rod Speed,dickhead,20
 BL> 3,Dave Begley,dogbreath,1,24,7,9,20,23
 BL> 12,Bob Lawrence,wallyburger,20

 PE> Repeating names here for no reason.

  The alternative is only allowing a name once, so how do you decide
which one to remove? Are you *sure* you're a programmer? I thought
that was the name of the game... silly logic?

 PE> Yatic just uses the address, not the name of the person. I
 PE> think the address by itself is fine.

  I've already decided to use an adress rather than a point number...
My objection to the address is that it is easy to get wrong, at both
ends. And in any case, you'll need a name in the cfg file so *you*
know who is who.

 PE> Although an optional field where I can put in the name (but it
 PE> doesn't do anything) is also fine. 

  Yair... it either has to be one or the other, name or address.

 PE> BTW, if you want to be "mean", you actually only need to worry
 PE> about "Special Requests", because that is all you use. I will
 PE> have to stew in my own Linux juice over the other TIC areas I
 PE> have (fortunately that is a small number, and I can kludge that
 PE> up and get away with it).

  I've more-or-less decided to do that, with just a single area, but
it's easy enough to build it in and let cfg sort it out.

  It's interesting writing in C again, but it's a shambles if you want
to make it run UNIX. 

Regards,
Bob
  
___ Blue Wave/QWK v2.12
@EOT:

---