In article <google.com>,
Brian K. White <com> wrote:
Sorry! The binary isn't actually smtpcull at all; it's smtpsrvr.
Here's what happened: I have an automated process that maintains the Armory
ftp archives by comparing every file in the archives to the "in-use" version.
If the in-use version is newer, the archive version is replaced with it, a new
helpfile is generated, etc. It knows where to find the in-use version of each
archive file. The in-use version of smtpcull is /usr/mmdf/chans/smtpsrvr,
since that's where it appears when it's being used.
But, I've been doing a lot of work on MMDF lately, and to test it on a
real-live-system, I copied all of the MMDF binaries over to
deepthought.armory.com, AKA ftp.armory.com. This of course replaced the
smtpcull front end for smtpsrvr with a new smtpsrvr binary. I didn't notice
that until the archive-update process ran, which mailed me a warning that it
hadn't been able to update the help page for smtpcull (since smtpsrvr doesn't
take a -h option). I fixed it (moved smtpsrvr to smtpsrvr.bin and put smtpcull
in place as smtpsrvr) and ran the update process again. It told me that it had
updated smtpsrvr, and I didn't noticed that it *didn't* tell me it had updated
smtpcull (since the in-use version was older than the binary that now resided
in the archives), so it stayed there waiting to trip you up :)
I've fixed that, and added code to the update process to check that the file
type of an archive file is identical to that of the source file that it would
be updated from.
John DuBois com KC6QKZ/AE http://www.armory.com/~spcecdt/