VIRECOVER(8) BSD System Manager's Manual VIRECOVER(8)NAME
virecover -- report recovered vi edit sessions
The virecover utility sends emails to users who have vi(1) recovery files.
This email gives the name of the file that was saved for recovery and instructions for recovering most, if not all, of the changes to the
file. This is done by using the -r option with vi(1). See the -r option in vi(1) for details.
If the backup files have the execute bit set or are zero length, then they have not been modified, so virecover deletes them to clean up.
virecover also removes recovery files that are corrupted, zero length, or do not have a corresponding backup file.
virecover is normally run automatically at boot time using /etc/rc.d/virecover.
/var/tmp/vi.recover/recover.* vi(1) recovery files
/var/tmp/vi.recover/vi.* vi(1) editor backup files
SEE ALSO vi(1), rc.conf(5)HISTORY
This script, previously known as recover.script, is from nvi and was added to NetBSD in 1996. It was renamed in 2001.
This man page was written by Jeremy C. Reed <firstname.lastname@example.org>.
BSD October 9, 2006 BSD
Check Out this Related Man Page
RECOVER(6) Games Manual RECOVER(6)NAME
recover - recover a NetHack game interrupted by disaster
recover [ -d directory ] base1 base2 ...
Occasionally, a NetHack game will be interrupted by disaster when the game or the system crashes. Prior to NetHack v3.1, these games were
lost because various information like the player's inventory was kept only in memory. Now, all pertinent information can be written out to
disk, so such games can be recovered at the point of the last level change.
The base options tell recover which files to process. Each base option specifies recovery of a separate game.
The -d option, which must be the first argument if it appears, supplies a directory which is the NetHack playground. It overrides the
value from NETHACKDIR, HACKDIR, or the directory specified by the game administrator during compilation (usually /usr/games/lib/nethack-
For recovery to be possible, nethack must have been compiled with the INSURANCE option, and the run-time option checkpoint must also have
been on. NetHack normally writes out files for levels as the player leaves them, so they will be ready for return visits. When check-
pointing, NetHack also writes out the level entered and the current game state on every level change. This naturally slows level changes
The level file names are of the form base.nn, where nn is an internal bookkeeping number for the level. The file base.0 is used for game
identity, locking, and, when checkpointing, for the game state. Various OSes use different strategies for constructing the base name.
Microcomputers use the character name, possibly truncated and modified to be a legal filename on that system. Multi-user systems use the
(modified) character name prefixed by a user number to avoid conflicts, or "xlock" if the number of concurrent players is being limited.
It may be necessary to look in the playground to find the correct base name of the interrupted game. recover will transform these level
files into a save file of the same name as nethack would have used.
Since recover must be able to read and delete files from the playground and create files in the save directory, it has interesting interac-
tions with game security. Giving ordinary players access to recover through setuid or setgid is tantamount to leaving the playground
world-writable, with respect to both cheating and messing up other players. For a single-user system, this of course does not change any-
thing, so some of the microcomputer ports install recover by default.
For a multi-user system, the game administrator may want to arrange for all .0 files in the playground to be fed to recover when the host
machine boots, and handle game crashes individually. If the user population is sufficiently trustworthy, recover can be installed with the
same permissions the nethack executable has. In either case, recover is easily compiled from the distribution utility directory.
Like nethack itself, recover will overwrite existing savefiles of the same name. Savefiles created by recover are uncompressed; they may
be compressed afterwards if desired, but even a compression-using nethack will find them in the uncompressed form.
SEE ALSO nethack(6)BUGS
recover makes no attempt to find out if a base name specifies a game in progress. If multiple machines share a playground, this would be
impossible to determine.
recover should be taught to use the nethack playground locking mechanism to avoid conflicts.
4th Berkeley Distribution 9 January 1993 RECOVER(6)