ACEDB source code documentation: database recovery

# Database Recovery

    In some rare occasions, the following crash has occured.
    Acedb works ok up to say session 100, but then when you attempt to
    save session 101, you get a crash:
      duplicate block in fusebat
    or some other low lying cryptic message.
    This amounts to a fatal unrecoverable error in session 100, which
    probably happenned while acedb was writing to disk during session 100.
    In some cases, we traced the bug back to wrong file authorizations,
    please verify that all files in the database directory belong to
    the database owner.
    If secveral user have write access, all these files should eb unix writable
    by those users. Forexample, you may
     chmod 775 database
     chmod 664 database/*
     chown -R acedb_group database
    and verify that all users are in the 'acedb_group' unix group
    or that the code is set group id:
    chmod 2755 xace tace

    Anyway, you may be able to recover from the crash in 3 different
    ways:

    ################################################################
    ## First method, a bit heavy, but no data is lost

    1) Open xace, it opens again as session 101.
    Dump the database from the menu of the main window
    create a new acedb in a fresh directory:
    cd somewhere
    mkdir wspec database
    cp oldwspec/* wspec
    setenv ACEDB `pwd`
    tace  // or xace

    and read back the dump files.

    If you crash while dumping because the address of some object
    is wrong, you can jump that object from beeing dumped by inserting
    it in a special keyset called DoNotDump

    create a new keyset from the menu in the keyset window
    use add/remove option
    add inthat keyset the object you want to avoid for
    example by using the main window to select them or
    by using the query language
     Find myclass myobject

    save this keyset under the name DoNotDump

    then dump the database
    during all this process, do not save the database and do
    not attempt to open the falty objects

    ################################################################
    ##Second method, very simple, but data from last session is lost

    2) You may backtrack to session 99
    To do so, from the menu of the main window, use session manager
    and then use the destroy_last_session button

    Then restart acedb, it will open on session 100, now a new
    daughter of session 99, and hopefully the problem is fixed.

    ################################################################
    ## Third method, totally crazy, avoid if possible

    3) If none of this works and you are a real hacker and
    you are totally desperate and the database will not open at all
    and you are completelly sure of the way you manipulate unix
    and you do not have any other way to recover your data from
    ace files, and you do not mind losing a whole day in vain, you
    may try the following which worked once for us:

    If the new superblock gets saved in a database, but not the
    control blocks it points to, the database becomes unreadable. By default,
    1 previous copies of the control blocks are kept, so it's possible
    to roll back the state of the database to a previous session. Here's
    how to do it.

    1) Look in the log.wrm file and determine the session number of the last
      saved session, attempt to roll back to a few less than this.

    2) Look in sysclass.wrm for the class no of _VGlobal.
       ( I don't know how to determine this in a new databse without sysclss.wrm
         assume that it's one. )

    3) Execute diskdump on the database blocks.wrm file. Each line represents
       one black and the fields are:
       class,  actual address, stored address, next address, key, session

    4) Look for all the blocks with class Global, class number is given by c=xx
       where xx is the hex class number.

    5) search in these blocks for ones whose session is equal to that
       you want to roll back to. Session is the last number on the line.
       eg, diskdump | grep 'c= 1' |  grep '612$'

    6) The keys have top eight bits class, and bottom 24 bits index.
       look for a key which is in one block only, probably 2.
       Hence a key of 1000002. Note the address of this block

    7) Run diskfix

    8) See if it worked.

    9) If it didn't, try an earlier session and repeat, that is, if any
    earlier session is available, which would be wrong by default.

    ################################################################
    ################################################################