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

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

  As I said, the guy who wrote YATIC was a psycho-potato. The idea of
an automatic system that sends you messages is oddly appealing... rofl!

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

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

  I don't know from BAD I only know GOODBYE. A bad TIC file is as
much use as another dick on the top of your head. I use the final
solution to the bad TIC problem. A. Hitler is my hero.

 BL> If it takes more than a few seconds, you need a quiet time with
 BL> no calls to do housekeeping.

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

  Of course you do. Two seconds, tops...

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

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

  That's what I was going to do, but it sorts so fast I may as well do
the whole thing. I was going to give specialr special status as the
letter-drop directory everyone can use, and if it's on the end of the
FILES list then it leaves most untouched in most cases. Of course, it
would still do all the areas listed. If Dave Begley uploaded crap in
his own area, it would just take a little longer to process.

 BL> It's just as easy to copy as to write a new one.

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

  And I'm just telling you I never follow existing prectice except as
a guide. I am an original thinker and my way is always best (except
when I'm wrong).

 BL> Does Binkley create files.bbs?

 PE> No, but maximus does, and every other bit of file-manipulation
 PE> 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.

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

  What's in a name? A bink by any other name smells the max. A max by 
any other name smells the same stinky bink.

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

  Thank you for sharing that with me, but as I said: TIC operates
independently. Max can stick files.bbs where the Bink don't shine.

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

  I certainly won't, Ollie.

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

  See? This is the inherent problem in more than one source of
information: you never know which one is right. My solution to this
problem is to check the actual directory and remove any lines that do
not have a file, and vice versa... add a line for every file, even
without a description.

  If you had just one directory for each section (my preferred option)
all you have to do is add and delete files from the disc, and FILES 
updates itself, deleting entries with no actual file on the disc, and 
adding a new entry for any new file (no description). You would have to 
go through FILES every so often and manually add descriptions, but you 
have to do that anyway.

  At a later stage, I'd be tempted to create self-writing headers, so 
that if you added a directory to the list, then FILES would automatically
add a new section. But it's not such a big deal to do it manually. 

 BL> You only create ONE file, so why do you need any more? Unless
 BL> files.bbs is created by Bonkley or something.

 PE> That way, f711x934.txt will be wrong if I go and delete a file
 PE> from c:\cooking and forget to update f711x934.txt.

  Nope. The next time you sort FILES it will delete the line with no
file. If you add a file, it will add a line (but no description).

 PE> CURRENTLY, if that happens, downsort will pick up that the file
 PE> doesn't exist, and change the description to "archived". ie it
 PE> does validation.

  My TIC just removes the line. Who cares about a file that isn't
there? You lose the description, but stiff bikkies.

 PE> But it doesn't clobber files.bbs with my description in it, it
 PE> just clobbers f711x934.txt (which is a GENERATED file). 

  My system would leave files.bbs so unclobbered that you could pickle
it in aspic and no one would notice. I simply don't use it.

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

---