[net.games.rogue] Save bug in 5.3 causes DELEATION of a DIFFERENT FILE!!!!!

laman@ncr-tp.UUCP (Mike Laman) (12/22/84)

There is a BAD bug in 5.3 rogue that I have not found in the 5.2 or the 3.6
versions.  It can cause a file (most likely to be ANOTHER saved rogue game)
to be DELEATED!

In a nutshell, if your try to save a game, specify that you don't
want to save the game in the first place it suggests, specify a second
file THAT EXISTS, and say that you DO want to save the game "over" the
second file, THE FIRST ASKED FILE WILL BE UNLINKED!  Yes, that first
file is removed, if rogue may "unlink()" it!  I will give a simple
"conversation" to illustrate the point (There are some simplier ways
but this is easy to understand and try).

1.  Run rogue.
2.  Save a game in the default place, let us say /users/me/rogue.save for this
    example.
3.  Run rogue again.
4.  Try to save the game, with 'S'.
5.  Rogue asks you if you want to save it at /usrers/me/rogue.save.
6.  You say no ('n').
7.  Rogue asks you where you want to save you game.
8.  You say /dev/null.
9.  Rogue says that it exists, and do you want to overwrite it?
10. You say yes.
11. The game is "saved" (:-)) in /dev/null, and you are now in the shell.
12. List /users/me/rogue.save.  Opps.  It's gone!

Maybe this will explain a couple people's cries of missing games.  I think it
has bitten me when I think back on past times.

Now for the fix.  In the routine "save_game()" is a call to "unlink()".
I can't give the offset (since I'm not on that machine anymore), but use
"?i" in adb and look at the instructions.  It is down a ways, so be patient.
There is only one call to "unlink()".  Look at the argument that gets passed.
On a VAX this looks like:

	pushaf	-80(fp)
	pushaf	.......
	calls	$2, _msg
	pushaf	_File_name		<------  Here is the line to change
	calls	$1, _unlink

Change the passing of "_File_name" to "-80(fp)".   Yep, you want the second
argument passed to "_msg()" above (that is what gets printed out showing
the file in which you are saving the game).

Don't try moving the "strcpy()" call from after the "unlink()" call to
in between the calls to "msg()" and "unlink()".  The logic is more
complicated than that!

Happy rogueing (and patching)...

		Mike Laman, System Roguer
		UUCP: {ucbvax,philabs,sdcsla}!sdcsvax!ncr-tp!laman