search

UIKit0 / hourglass-win32

Automatically exported from code.google.com/p/hourglass-win32
0 stars 0 forks source link

Useful file-handling interception. #5

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Looking at the source code, I see that at least one file-accessing function is 
hooked, however, practical experimentation shows me that there is no 
verification of file contents, which leads to a massive hole in sync-robustness 
as, for instance, playing the same input file twice may lead to resuming from a 
savegame created during the first playback.
I see two possibilities to address this, each with strengths and drawbacks:

The first method I see to address this is copying files' contents into the 
windows tas file when they are first accessed during recording, then, on 
playback, when a file is accessed, the pointer is redirected to the version 
embedded within the wtf file. The drawbacks to this method are that it is 
complex to implement, it probably requires compression to avoid bloating the 
wtf files to a ridiculous extent, and it may expose users to legal risk as they 
are passing around the data files of whatever games they submit TASes of. 
However, this is probably the most sync-robust solution.

The second method I see is to get a checksum of a file whenever it is accessed 
during recording, and warn if there is a mismatch of file contents during 
playback. This method is much easier to implement, and incurs no legal 
concerns, but may leave users confused and frustrated if a TAS is accidentally 
recorded with files in a non-initial state.

Original issue reported on code.google.com by Upth...@gmail.com on 7 Jun 2011 at 12:30

GoogleCodeExporter commented 9 years ago 
How about:
- Store the pre-modified contents of any files that were attempted to be 
modified during recording.
- Store the checksum of any files that were read but not modified during 
recording, and warn about any checksum mismatches of these files during 
playback (via a dialog box that has an option to suppress further warnings).
- When starting or stopping playback or recording, restore the contents of 
files that were modified by the game during either the current movie or the 
previously-open movie.
- If possible, during playback and recording, don't actually modify any files 
on the filesystem. Instead, make the applicable file functions pretend to 
succeed and keep the changes in memory.

I've stayed away from this feature until now because I think LOTS of traffic 
goes through the low-level file-accessing functions and it might not be totally 
straightforward to avoid negatively impacting the performance or stability when 
hooking them.

Original comment by nitsuja-@hotmail.com on 7 Jun 2011 at 6:15