BL> 1.  Check/accept files

BL> Check the inbound for .TIC
BL> Read file name and check that the file exists
BL> Read the point name, password, and area.
BL> Check the password, and area access.
BL> Move the file to the correct directory.
BL> Add the file details in a line on the end of the FILES.TXT

PE> This is not what TIC does at the moment, it just adds it to the
PE> FILES.BBS at the end. 

BL> Then what the hell point is there in having passwords? Jesus!

Sorry, my comment only related to the last line.

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

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

BL> Add the name and date to "LATEST FILE" field in header

PE> Current operation is to get the name and date when creating the
PE> file list. 

BL> I'm not sure what you mean. I was going to check that the file is 
BL> in the directory, and then create a full entry line using name, size, 
BL> time/date and description. Then the FILES would be sorted, updated, 
BL> and correctly structured at a later time using the directory as the 
BL> reference.

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

PE> That is what happens now. You can FREQ something straight away.
PE> What you can't do is get an updated files list, because that
PE> only happens once/day. Although now that it's so fast, maybe I
PE> should add that. 

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

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

BL> This is how I make sure that *only* the files in the directories are
BL> on the list. With two sources of information (the directory and the
BL> FILES list) you need to have a master.

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

PE> I don't think you should read the input from an old output, it
PE> should be read from another file. Just specify that I have to
PE> pass a file with a header in it as parameter 1. 

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

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

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

There's no headers in files.bbs.

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

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

1. Maximums control file and recompiling.

2. Creating the directory.

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

BL> the header template (or vice versa). The FILES structure has an
BL> inherent weakness: no way in the structure to link number, name and
BL> actual directory path.

The f711x934.txt should preferably only be written by a program, read by a
user, not read by a program.

PE> Current practice is to generate the lot from scratch. That's
PE> not a problem, and should be simpler and safer. 

BL> Each entry in FILES must have a rweal file behind it or what's the 
BL> point? It's a fallacy to think it's safer... it's actually worse! At 
BL> present, we have a set of directories with *real* files you can use; 
BL> a FILES list in a pretty format of numbered and named sections with 
BL> file names, dates, size and description, and another set of differently 
BL> formatted names and descriptions kept in separate sections. How is it 
BL> safer to have three sets of information? That only applies if one is a
BL> master than never changes, but that is not the case. All three change
BL> daily!

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

BL> I've been writing TIC as a standalone system that takes a .tic file,
BL> checks it, adds the file to the appropriate directory and the entry to
BL> the FILES list, and then updates the FILES list when convenient. It

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

BL> 1.  A list of Area number, name, and actual directory.  

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

BL> 2.  A list of points, password, and permitted access.

Yes, they have this in yatic too.

BL> I still think it's better to do it this way and make TIC an add-on,
BL> rather than stuff around trying to make it work with... whatever.

Yes, they are already stand-alone.

BL> The format of my DATA file is this...

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

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

BL> At the very least, each entry needs a number and a directory, or all 
BL> entries will be removed. It can be just one directory if you like, as
BL> long as it knows where to look for the file names. 

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

Repeating names here for no reason.  Yatic just uses the address, not the
name of the person.  I think the address by itself is fine.  Although an
optional field where I can put in the name (but it doesn't do anything) is
also fine.

BL> The TIC format you posted does not have a name, so I had to use the
BL> point number. I could use the address just as easily.

Yes, that is the way to go.

BL> The way I see TIC, it runs totally independently of the rest of the
BL> BBS, as an automatic add-on. All it does is let points post files in
BL> selected areas, 

Yes, that is right.

BL> and create a daily FILES list. I'd just as soon not

No, that's a separate task.

BL> get involved with MAXIMUS or whatever.

I don't care how you want to specify the area names.

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

---