> Jun 29 15:37:58 :: Loading zone table.
> Jun 29 15:37:58 :: 35 zones, 980 bytes.
> Jun 29 15:37:59 :: SYSERR: world/zon/0.zon is empty!
Scenario 1:
in db.c, load_zones() (approx. line 1391), there should be code something
like:
if( num_of_cmds == 0 ) {
log( "SYSERR: %s is empty!", zname );
exit( 1 );
} else
...
This is where the SYSERR message you're seeing is generated. At this point
in the code, the file has already been successfully fopen'd, so the
likelihood is high that it is at least finding your 0.zon file.
Now, either the code immediately above this "if" statement is flawed, or the
if statement itself states:
if( num_of_cmds = 0 ) {
which will always return TRUE, causing your boot-up to abort.
I got bored and downloaded the stock bpl17 code, and it looks like the if
statement is correct. But what I did notice was this:
num_of_cmds gets incremented based on the successful return of the
get_line() function call, in utils.c. get_line() has changed in bpl18.
Among other things, a call to feof() has been removed, which, when true in
bpl17, causes get_line() to return zero. And consequently, num_of_cmds
would not be incremented.
I'm not a Windows hitter, but if I were you, I'd check the documentation on
feof() for your compiler and see whether it follows the K&R spec. This
certainly wouldn't be the first time Microsoft got its own idea about how a
function call should behave (yeah, I know, no OS bashing, but if this really
is the case, MS earned the abuse).
Or, just download the bpl18 code and see if the problem persists. The
changelog didn't specifically mention why the feof() call was removed, but
odds are it was done for a reason.
Scenario 2:
After compiling, you're executing the code from the wrong basepath. The
world pathnames are not fully rooted, so that would cause you some problems.
Theoretically, you could have a duplicate lib path that contained index
files and empty *.zon files, which would cause this type of error. *shrug*
This is unlikely to be the case, but I mention it as something to look at.
Plus, I would have expected the program to blow up long before the "empty
file" message. Still, one could pathologically set up an environment that
would cause this scenario to occur.
> Im going to
> reinstall and try that.
Ugh. I wouldn't reinstall your OS before checking the code first.
One last thing: when using pre-compiled software, all bets are off. You
have no way of ensuring (well, short of a binary comparison) that a given
codebase was used to generate that binary. If you're happy relying on
others to do the codework, by all means use pre-compiled software.
Otherwise, pay the dues and get a source base up to speed.
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/05/01 PST