Lost RESOURCE.001 file, possible corruption

[ViolentValence]

I'm needing the advice of Gumby & company, of all you helpful SCI types.

I've managed to make my resource.001 file disappear, through a combination of having to minimize a running instance of my game (I was caught in an infinite loop of gProgramControl remaining permanently TRUE), and, inexcusably, attempting to compile my scripts without realizing the game was still running in my taskbar (win XP.) The resources seemed to be wiped, 'repair resources' produced an error (I'll see what I can do about finding it, is there a log for those?), and the resource.001.bak file became a sturdy 0 bytes, and backing up a file that seems to have never existed.

Does the compiler have some kind of temp, phantom place it may have ferreted it away to?

SO very much work at stake. Eternal gratitude, my firstborn's name, cashmoney for any leads.

 P.S. keep up the fine work!

[gumby]

I've had this happen before too.  It's like you've corrupted your game while it was running  twice, which creates an empty backup (a backup of the corrupted empty resource.001.

Good news is that your script resources should be fine - you've got the source files, bad news is that any other resources (views, room pics, etc) that you haven't manually exported are gone.

After this happened to me several times, I started backing up my games in development regularly.

[Collector]

http://sciwiki.sierrahelp.com/index.php?title=Resource_Corruption_from_Rebuilding_while_Running

This is where it would be good to have an active developer for Studio or Companion. It would not be that hard to add a check to prevent compiling if the game was running, automatically force close DOSBox or to automatically rename the backup to keep the earlier backup. Perhaps, at least to keep a store of unpacked individual resources. I can think of a number of different ways to prevent it or make recovery painless. If my C++ skills were at least where my .NET are, I would take a stab.

[gumby]

Sure, good idea.  However, since upgrading to Win 7 I haven't had any corruption issues.  Probably exclusive file locks.

In my opinion, XP could definitely use a fix (and previous OS'es too).  We could just hack together a new 'RUN' executable (like the one used in DosBoxRunSetup) that backs up the entire game folder before running the game?

[Collector]

It would be possible. Currently, the RUN.EXE is little more than a compiled batch file. I could do a more involved version that would copy the game to the temp folder and run the game in DOSBox from there. Not so much a backup function, but that way the game would only ever be run from a copy and not touch anything in the development folder.

[gumby]

Another possibility would be to create a new folder named with a timestamp. That would provide a pretty good backup strategy.  If you ran your game 5 times today, you'd have 5 backups.

[ViolentValence]

Ah, that's as I feared. Thx very much for the prompt replies. I'm looking forward to one day contributing to the fangames section.

[Collector]

Another possibility would be to create a new folder named with a timestamp. That would provide a pretty good backup strategy.  If you ran your game 5 times today, you'd have 5 backups.

I could see that getting out of hand. If you were trying to work out a problem, you might run the game many more times than that in a short period of time. You could do an automatic delete of the older versions, say any but the five most recent, but I am a little loath to do automatic deletion of anything other than temp files. On the other hand, a backup could also do a view and pic dump, but that might not be that useful as long as a good means of preventing corruption or auto backup was implemented. I'll have to experiment with a couple of these ideas and see what I can work out.

BTW, Gumby. Before Windows 7, were you using DOSBox or the NTVDM to run the game? The game files under NTVDM would probably be subject to file locking. DOSBox may avoid this with all but the main executable.

[gumby]

I was using the 'stock' install of Studio/Companion which uses the VTVDM.   I never did use the DosBox setup within XP.

Another alternative could just be one backup per day.  Perhaps the first time you ran a game in a calendar day, the backup would run?

[Collector]

Then perhaps it is more of a problem with running it with NTVDM than with DOSBox. I am going to do an installer for Companion and Studio that will include the DOSBoxRun app. It would also solve the problem of Companion's help file needing permission to be opened.

I have started to play around with different approaches for the DOSBoxRun app. This version just backs up the RESOURCE.001 and the RESOURCE.MAP to a date stamped folder and then runs the game. You will need to rename the RUN.BAT to DOSBOX.BAT.

[gumby]

For those interested, here's how I reproduced the fatal problem (Windows XP):

1) Start your game up
2) Rebuild your resources - this will throw an error & cause backup files to be created (.bak)
3) Rebuild your resources again - this will throw the same error & overwrite your previous good backups with zero byte files
4) Return to the running game and close it.  This will remove the map & resource files leaving you with nothing.

[gumby]

Important followup, please read:

If you use DosBox to launch your games, you will be protected from corruption.  I repeated my previous test, here are my findings (again in Win XP).

1) Start game
2) Rebuild resources.  This will create backups of the .001 and .MAP file
3) Rebuild resources again.  The original backups will not be replaced with zero byte files
4) Close game.  Note that the original .001 and .MAP files are not deleted.

It appears that while using DosBox, the generated BAK files are redundant & your game will not corrupt.

[Collector]

So I guess that having the Run utility do an auto backup is redundant. It avoids the problem altogether. The RESOURCE files must not be locked when they are in use by SCIV.EXE in DOSBox the way they are when SCIV.EXE is when running under the NTVDM.