don@axiom.UUCP (Donald F. Picard) (05/01/85)
[]
There is a bug in version 1.0.1 ( I don't know if it is in 1.0.2 because
I haven't brought it up yet) in the file "hack.stat.c". The game
checks the inode change time of files against the inode change time of
the game to make sure that they (the files) are up to date. I assume
that this is an attempt to make sure that people are not trying to
restore saved games (and ghost levels) that were created under a previous
version of the game. The only problem is that the inode change time
gets updated for a lot of reasons, not just "file creation".
I recently lost a saved game (and a good one too!) because somebody here
made a symbolic link to the game. (Don't ask me why.) This updated the
inode change time of the game and so the next time I tried to play
it told me that my saved game was out of date and threw it away!
I don't know why the author chose to check the c_time field over the
m_time field, but that is my suggested fix.
A context diff follows.
Don Picard
Axiom Technology
... linus!axiom!don
*** hack.stat.c
--- hack.stat.c.new
***************
*** 17,23
pline("Cannot get status?");
return(0);
}
! if(buf.st_ctime < hbuf.st_ctime) {
pline("Saved level is out of date.");
return(0);
}
--- 17,23 -----
pline("Cannot get status?");
return(0);
}
! if(buf.st_mtime < hbuf.st_mtime) {
pline("Saved level is out of date.");
return(0);
}siritzky@acf2.UUCP (Brian Siritzky) (05/02/85)
/* acf2:net.games.hack / don@axiom.UUCP (Donald F. Picard) / 7:14 pm Apr 30, 1985 */
[]
There is a bug in version 1.0.1 ( I don't know if it is in 1.0.2 because
I haven't brought it up yet) in the file "hack.stat.c". The game
checks the inode change time of files against the inode change time of
the game to make sure that they (the files) are up to date. I assume
that this is an attempt to make sure that people are not trying to
restore saved games (and ghost levels) that were created under a previous
version of the game. The only problem is that the inode change time
gets updated for a lot of reasons, not just "file creation".
I recently lost a saved game (and a good one too!) because somebody here
made a symbolic link to the game. (Don't ask me why.) This updated the
inode change time of the game and so the next time I tried to play
it told me that my saved game was out of date and threw it away!
I don't know why the author chose to check the c_time field over the
m_time field, but that is my suggested fix.
A context diff follows.
Don Picard
Axiom Technology
... linus!axiom!don
*** hack.stat.c
--- hack.stat.c.new
***************
*** 17,23
pline("Cannot get status?");
return(0);
}
! if(buf.st_ctime < hbuf.st_ctime) {
pline("Saved level is out of date.");
return(0);
}
--- 17,23 -----
pline("Cannot get status?");
return(0);
}
! if(buf.st_mtime < hbuf.st_mtime) {
pline("Saved level is out of date.");
return(0);
}
/* ---------- */don@axiom.UUCP (Donald F. Picard) (05/02/85)
[] >I recently lost a saved game (and a good one too!) because somebody here >made a symbolic link to the game. (Don't ask me why.) This updated the >inode change time of the game and so the next time I tried to play >it told me that my saved game was out of date and threw it away! My apologies. Making a symbolic link to the game does not change the inode c_time. However, a failed hard link does! When I was trying to find out what happened, I first tried to do a hard link (which failed because it could not cross file systems). I assumed that this meant it did not update the c_time field. I then tried a symbolic link (which worked), so when I checked the c_time field and noticed that it had changed, I attributed the change to the symbolic link. Foolish me. I still think that this is a bug. Don Picard Axiom Technology ... linus!axiom!don