Community
Participate
Working Groups
Currently snapshots are taken before save, investigate updating this to a write and copy cycle for the next release to help guard against VM crashes.
Remaining failure scenario: 1) write takes place but gets corrupted in the process (file exists and is > 0 bytes and is corrupt) 2) system remains operational (i.e. NOT a VM crash so workbench remains). The case of recovering from corruption upon reading is already handled. 3) upon subsequent save, the snapshot taken is of a corrupt file wiping out a good backup If this (tricky) scenario happens we now have two corrupt files instead of one corrupt and one good snapshot. Unfortunately, even if we are writing to a temp file and then copying, we may still overwrite a perfectly good file with a corrupt one if upon write the stream is unknowingly corrupted. Our only option here may be to verify the file before copying (be it the existing copy -> write solution or the write -> copy alternative).
Since last fix to activity persistence, we haven't had report of more failures. Looking into background information before proceeding with any further optimization. If I can locate some solid literature on this then we might be able to apply it to 3.1.
The current model has been working well.
