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. 

BL> Eh? If the file is not there, then the transfer *has* to abort. If
BL> the file arrives without the TIC, yu'll end up with a file and nothing
BL> will happen. 

That's exactly what I want, instead of yatic complaining "file not
found", and RENAMING the .TIC file to .BAD, and that's the last time
it's looked at.

BL> Wouldn't it be better to send the TIC first? At least it
BL> would abort automatically when it didn't find the file.

And rename it to .BAD, which I don't want!

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. 

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

?!  You think I currently take all the .MO0 files you send me (or Dave
sends me, like megabytes worth), and quick as a wink, I decompress all the
archives, run the 50 .PKT files through Tobruk, get squish to compress all
the .PKTs into zips (called .MO0 etc)?

Binkley exits so that the mailprocessing can be done, after EVERY CALL. I
also call yatic after EVERY CALL.  It's not a problem.

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

I have a files.bbs in every directory, including specialr.  All you need to
do is add the filename and description to the end of files.bbs.  Unless the
file was already named in files.bbs, then you need to delete the old entry
and then do the append.

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

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

Why not?  Existing practice.  I'm just telling you how things run at the moment.

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

BL> Does Binkley create files.bbs?

No, but maximus does, and every other bit of file-manipulation software.

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

No, the binkley okfile1.txt file lets you FREQ, here is what it looks like:

c:\bbssoft\*.*
c:\specialr\*.*
{at}tobruk c:\bbssoft\tbk0*.*
{at}devil c:\minpoint\devil*.*

You don't need to touch or view this file though.

BL> AFAIK, your existing system keeps names and descriptions in 24
BL> separate files, plus the headers in another file linked to the names
BL> of those files, plus files.bbs as a raw *sorted* file with
"archived"

The files.bbs doesn't have "archived" in it. 
"archived" means "files.bbs is wrong", ie there is a
description, but no physical file.

BL> and where-did-it-go, and finally where it all comes together as
BL> f711x934.txt. By simply logic, it is possible to eliminate everything
BL> up to the final FILES list... and you *should*.

I don't think there's anything actually wrong with the current use of
files.bbs.  Yes, you can create an alternative scheme to replace it.

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

That way, f711x934.txt will be wrong if I go and delete a file from
c:\cooking and forget to update f711x934.txt.  CURRENTLY, if that happens,
downsort will pick up that the file doesn't exist, and change the
description to "archived".  ie it does validation.  But it
doesn't clobber files.bbs with my description in it, it just clobbers
f711x934.txt (which is a GENERATED file).

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

Unix is no more of a shambles than MSDOS.  In fact, it's far better. BFN.  Paul.
@EOT:

---