Backup databases not being written to $GAMEDIR/backup

[blightbow]

Original issue 37 created by ZetaMUCK on 2014-10-18T21:01:24.000Z:

The problem is inside of dump_database_internal():

 308|         if (tp_dump_copies > 0) {
 309|             copies = (tp_dump_copies < 25) ? tp_dump_copies : 25;
 310|             for (; copies > 1; copies--) {
 311|                 sprintf(fromfile, "backup/%s.#%d#", dumpfile, copies - 1);
 312|                 sprintf(destfile, "backup/%s.#%d#", dumpfile, copies);
 313| #ifdef WIN_VC
 314|                 unlink(destfile);
 315| #endif
 316+>                rename(fromfile, destfile);
 317|             }

(gdb) print (const char *)fromfile
$12 = 0xbfdbfdc8 "backup/data/proto.new.# 9#"
(gdb) print (const char *)destfile
$13 = 0xbfdbffc8 "backup/data/proto.new.# 10#"
(gdb) print dumpfile
$21 = 0x9d62c58 "data/proto.new"

If the game is started with a dumpfile containing a directory path (which the current restart script does; I deliberately moved the database files back to the data directory), the rename() call will end up failing as this directory path does not exist inside of the backup directory.

fromfile and destfile need to be defined in a way that strips out only the filename component of dumpfile.

[blightbow]

Comment #1 originally posted by ZetaMUCK on 2014-10-19T00:15:23.000Z:

On further research, this is basically a long chain of fail that we've inherited from upstream Proto.

• As stated above, the rotation code injects user input into the filename, which may or may not contain a directory. This has always been the way it works, going as far back as ProtoMUCK 1.0. In other words, this problem does not involve any source code changes.
• The backup/data directory has never been shipped as part of ProtoMUCK. The backup/ directory exists, but it has no subdirectories. It is not in trunk for proto1.0, proto2, protomuck, etc. This can be confirmed by browsing the following location: https://code.google.com/p/protomuck/source/browse/#svn%2Ftrunk
• Basically, the only games that had working backup rotations were migrated NeonMUCK sites that already had a backup/data directory. If you started your game under ProtoMUCK, this directory did not exist and you were not getting rotations in the backup directory.
• Alynna's short-lived restart script framework (the muck.config thing) inadvertently relocated databases from game/data to game/. This had a side-effect of enabling backup rotations for any site, since the output file argument fed to the protomuck binary would no longer contain a subdirectory.
• When I replaced Alynna's framework with my own, databases resumed being written to the data/ subdirectory. This disabled backups again for sites that did not have a game/data directory.

Temporary workaround: create a backup/data directory. This will ensure that you have backup rotations no matter what, but the root cause still needs to be addressed: the directory location that these database files are being written to should be in no way influenced by how the game is started up.

[blightbow]

Comment #2 originally posted by ZetaMUCK on 2014-10-19T20:28:20.000Z:

This issue was updated by revision r120.

Added game/backup/data/ subdir to trunk as a breakfix for people starting new sites.

[blightbow]

Akari reported another variant of this bug. The current restart script will pass in absolute paths to proto.db and proto.new as a result of directory autodetection. The backup code expects the path to the passed in database files to be relative, not absolute. This results in backup filenames that look like this:

(gdb) print (char *)fromfile
$7 = 0x7ffd64cb3d00 "backup//home/motm/motm/staging/game/data/proto.new.#9#"
(gdb) print (char *)destfile
$8 = 0x7ffd64cb3b00 "backup//home/motm/motm/staging/game/data/proto.new.#10#"

The end result is that the restart script prevents backups from being written even if the backup/data directory exists. This code should be rewritten to utilize logic similar to how paths are constructed to files in the muf and info directories.