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. 

  Then what the hell point is there in having passwords? Jesus!
Doesn't it even check if the file is there?

 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. 

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

 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. 

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

 BL> Read a directory (starting at #1) for list of file names. Sort
 BL> names

 PE> I don't think there is any requirement for this.

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

 BL> Read FILES.TXT, copy section header. 

 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. 

  I thought about this... but what's the difference? I *have* to read
the file name and description from a file that is constantly updated,
and if I can trust *that* not to degenerate then why not trust it for
the headers too?

  Using a separate header template adds another way to get screwed up,
if for instance you added a new section in FILES but forgot to modify
the header template (or vice versa). The FILES structure has an
inherent weakness: no way in the structure to link number, name and
actual directory path.

 BL> If no name in FILES.TXT add a new line with no description

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

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

  My solution is to nominate the actual directories as the master and
generate a single FILEs list from that, using the existing FILES list
for file description only. It is actually safer to take this information 
from the FILEs list rather than generate a files list from another list 
that has been also been updated.

 PE> Another thing is that I will sometimes add a file (like
 PE> CVS19.ZIP) by myself, by editting files.bbs directly. 

  This is no problem, as long as you put it in the correct section and
have a *real* file in the correct directory. If not, the next update
will check the directory and leave out any FILES entry that is not
correct. If you entered the wrong date, for instance, my system would
adjust it to match the directory entry.

  You can see the possibility of error, though.

  I assume that each section in your files list has a number, a name,
and an actual directory. They could be mixed any way, but to make my
system work I need a master list.

 PE> That is kept in a different file, I'll post an excerpt from
 PE> that file.

 PE> Area 1
 PE> FileAccess      Disgrace

 PE> FileInfo        Stuff required for FREQing/pointing
 PE> Download        C:\MINPOINT\
 PE> Upload          File\Uncheck\
 PE> End Area


 PE> Area 3
 PE> FileAccess      Sysop

 PE> FileInfo        BBS Related Stuff
 PE> Download        C:\BBSSOFT\
 PE> Upload          File\Uncheck\
 PE> End Area

  I've been writing TIC as a standalone system that takes a .tic file,
checks it, adds the file to the appropriate directory and the entry to
the FILES list, and then updates the FILES list when convenient. It
needs the inbound and outbound directories (to know where to look for
TICs, and where to post replies) and it needs a data file consisting of 
the following:

1.  A list of Area number, name, and actual directory.  
2.  A list of points, password, and permitted access.

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

  The format of my DATA file is this...

[Areas   number, directory, TIC name, list name]

1,c:\rswipe,PCOOK,Paul's cooking list
2,d:\Iforget,DOGGY,10000 X-rated dalmatians
3,c:\rswipe,USLS,10000 totally useless files
4,c:\bbsoft,ELLE,10000 tits
5,c:\bbsoft
20,c:\bbsoft,SPECIALR,Special Requests

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

[Points      point number, name, password, Area access allowed]

1,Rod Speed,genius,1,2,3,20,25
2,Rod Speed,dickhead,20
3,Dave Begley,dogbreath,1,24,7,9,20,23
12,Bob Lawrence,wallyburger,20

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

  The way I see TIC, it runs totally independently of the rest of the
BBS, as an automatic add-on. All it does is let points post files in
selected areas, and create a daily FILES list. I'd just as soon not
get involved with MAXIMUS or whatever.

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

---