[Coldstuff] DB backup issues when compressed...

[Brandon Gillespie]

On Mon, Feb 18, 2002 at 08:20:09PM -0800, Jonathan Robertson wrote:
> Ok.. I've gotten myself into somewhat of a problem. 
> Recently I created my own backup script as part of a
> shell script and I scheduled the backup to run every
> hour and to reschedule itself every day... On to the
> problem...
> 
> Last thursday Genesis stopped running on my server for
> some reason or another, and as you probably well know
> if it doesn't close properly the DB will be corrupted
> which it was.  I got on the server and attempted to
> restore the most recent backup (only 20 minutes old)
> and it appeared to restore properly from the console. 
> Fired up Genesis and got the "Corrupt Binary Database"
> error message.

Most likely the backup itself wasn't marked as clean... there is a way
to cheat genesis (but it isn't necessarily stable) by copying the
.clean file from a good binary db into the one genesis is claiming is
'corrupted'... Basically, it isn't really doing any checksums or
anything, just looking for the .clean file.

If you do that, I'd recommend copying in the .clean file, running a
decompile and then a recompile.

> My script compresses the
> /cold/binary.bak folder.  The command I used was
> 
> tar -czf /cold/backups/BU.$(date...) /cold/binary.bak
 
Perhaps you did it before genesis was done backing it up?

> Any Suggestions?  I don't want to lose any more than I
> absolutely *have* to.  As I am going to rewrite it
> again and say nevermind on the compression, I'll just
> use a CDRW every week or so rotating them monthly. ;)

Use the backup2 script (included with the latest coldcore put out a
few weeks ago, but not before then).  This script decompiles to text
for a few reasons:

 1-Its more portable/archivable
 2-It Emails an admin if it cannot decompile the DB (so you know
   immediately if there is a problem)
 3-It avoids stacking lots of corrupted backups, or is less likely to,
   because it'll email the admin

As for backing up both... I dont see why you would want to do this?
The Binary database is a non-portable run-time format used only for
the execution of the current server, it isn't re-usable between
OSes, server versions, or even recompiles with alternate
opcodes--without first doing a decompile/recompile with coldcc.

> 1. What platforms does "Cold" program using? ie the
> developers of the initial Genesis, coldcc...                                  

unix in general is ok.

> 2. Is anyone currently running Genesis on a Windows
> 2000 Server?  if so are you having any issues?                                

Some people do... my personal main concern would be signal handling...
I dont think it would be a problem to use it in personal development,
but I'd never run it as a server under Win32--primarily because its not
its native platform.

> 4. Is there a way to look at a "binary" DB and edit it,
> or get parts of it to decompile to a textdump file?                                                                         
yes, you can mangle the snot out of a binarydb using the 'coldcc -p'
(patch) argument.  It uses the exact same syntax as a textdump but
rather than create a new db, it opens an existing one.  Just remember
to not use 'new' because that'll blast the existing object, if there
is one (i.e. new object $root bad, just do 'object $root' to load the
root object).

>From there use 'eval' which is like a non-method:

eval {
    ColdC code
};

Checkout the test suite to see some extensive uses of eval.

As for decompiling only parts of it, no luck there... it is all or
nothing.  I had considered back in the day having an exclude/include
argument to coldcc, where you could give it object numbers to skip
(for the cases where the db is corrupted) or only decompile (for the
cases where you just want to dump one object).  Feel free to dig into
textdb.c and add it as an option, I'm sure Bruce wouldn't mind the
patch :)

-Brandon