Shishi: file modification time makes build hashes unpredictable

[invadermonks]

If you patch a tactics bin with a shishi_import directory with images, sprites or a .shishipatch twice, the resulting md5 hash will be different each time. Dumping the files from the iso shows that most of the SPR files in the BATTLE directory have a modified time from today rather than 1997. Shishi should avoid writing modified time metadata (or clone it from the source iso) and should produce the same output given the same input consistently.

[Glain]

@invadermonks I'm not able to reproduce this... can you provide an input where this happens?

[invadermonks]

Sure here is a test case with the .497 build, you can place a vanilla fft.bin, the attached test_shishi.bat and the test_shishi folder with a shishipatch in it to the root of the FFTPatcher folder and run test_shishi.bat to run the testcase. This is the output of the bat file when I run it:

MD5 hash of fft.bin: b156ba386436d20fd5ed8d37bab6b624 CertUtil: -hashfile command completed successfully. copy fft.bin fft-test1.bin 1 file(s) copied. start /wait "Patch" ShishiSpriteEditor.exe -expand -patch test_shishi fft-test1.bin Applied patch file: C:\Users\invadermonks\Documents\FFTPatcher_497\test_shishi\test.shishipatch

MD5 hash of fft-test1.bin: 9f2a8ce062b7d4b5a28abd6640409565 CertUtil: -hashfile command completed successfully. copy fft.bin fft-test2.bin 1 file(s) copied. start /wait "Patch" ShishiSpriteEditor.exe -expand -patch test_shishi fft-test2.bin Applied patch file: C:\Users\invadermonks\Documents\FFTPatcher_497\test_shishi\test.shishipatch

MD5 hash of fft-test2.bin: e35326c94d38b17b62a25f15aee26e14 CertUtil: -hashfile command completed successfully. Press any key to continue . . .

You can see that running the same Shishi patch process twice results in two different MD5s for the resulting disc image.

test_shishi.zip

[Glain]

Thanks, I was able to reproduce with that input!

It wasn't the patching of the .shishipatch that was causing the issue, though... it was expanding the ISO, which creates new directory entries for the new files, including timestamps.

The issue should be fixed now with these changes:

• You can now expand the ISO from the command line without patching (-expand fft.bin) (af9deee)
• Expanding the ISO uses a static date (1/1/2000) for the new directory entries (0b25423)

[invadermonks]

Just tested this on the newest revision, works great and gives me consistent builds. Thanks!