1RECOVER(6) Games Manual RECOVER(6)
2
6 recover - recover a NetHack game interrupted by disaster
7
9 recover [ -d directory ] base1 base2 ...
10
12 Occasionally, a NetHack game will be interrupted by disaster when the
13 game or the system crashes. Prior to NetHack v3.1, these games were
14 lost because various information like the player's inventory was kept
15 only in memory. Now, all pertinent information can be written out to
16 disk, so such games can be recovered at the point of the last level
17 change.
18 The base options tell recover which files to process. Each base option
20 specifies recovery of a separate game.
21 The -d option, which must be the first argument if it appears, supplies
23 a directory which is the NetHack playground. It overrides the value
24 from NETHACKDIR, HACKDIR, or the directory specified by the game admin‐
25 istrator during compilation (usually /usr/games/nethack-3.4.3).
26 For recovery to be possible, nethack must have been compiled with the
28 INSURANCE option, and the run-time option checkpoint must also have
29 been on. NetHack normally writes out files for levels as the player
30 leaves them, so they will be ready for return visits. When checkpoint‐
31 ing, NetHack also writes out the level entered and the current game
32 state on every level change. This naturally slows level changes down
33 somewhat.
34 The level file names are of the form base.nn, where nn is an internal
36 bookkeeping number for the level. The file base.0 is used for game
37 identity, locking, and, when checkpointing, for the game state. Vari‐
38 ous OSes use different strategies for constructing the base name.
39 Microcomputers use the character name, possibly truncated and modified
40 to be a legal filename on that system. Multi-user systems use the
41 (modified) character name prefixed by a user number to avoid conflicts,
42 or "xlock" if the number of concurrent players is being limited. It
43 may be necessary to look in the playground to find the correct base
44 name of the interrupted game. recover will transform these level files
45 into a save file of the same name as nethack would have used.
46 Since recover must be able to read and delete files from the playground
48 and create files in the save directory, it has interesting interactions
49 with game security. Giving ordinary players access to recover through
50 setuid or setgid is tantamount to leaving the playground world-
51 writable, with respect to both cheating and messing up other players.
52 For a single-user system, this of course does not change anything, so
53 some of the microcomputer ports install recover by default.
54 For a multi-user system, the game administrator may want to arrange for
56 all .0 files in the playground to be fed to recover when the host
57 machine boots, and handle game crashes individually. If the user popu‐
58 lation is sufficiently trustworthy, recover can be installed with the
59 same permissions the nethack executable has. In either case, recover
60 is easily compiled from the distribution utility directory.
61
63 Like nethack itself, recover will overwrite existing savefiles of the
64 same name. Savefiles created by recover are uncompressed; they may be
65 compressed afterwards if desired, but even a compression-using nethack
66 will find them in the uncompressed form.
67
69 nethack(6)
70
72 recover makes no attempt to find out if a base name specifies a game in
73 progress. If multiple machines share a playground, this would be
74 impossible to determine.
75 recover should be taught to use the nethack playground locking mecha‐
77 nism to avoid conflicts.
784th Berkeley Distribution 9 January 1993 RECOVER(6)