Question

I’m adding autosave functionality to a graphics application in Java. The application periodically autosaves the current document and also autosaves on exit. When the user starts the application, the autosave file is reloaded.

If the autosave file is corrupted in any way (I assume a power cut when the file is in the middle of being saved would do this?), the user will lose their work. How can I prevent such situations and do all I can to guarantee that the autosave document is in a consistent state?

To further complicate matters, to autosave the document I need to save one .xml file and several .png files. Also, the .png saving occurs in C code over JNI.

My current strategy is to write each .png with the extension .png.tmp, write the .xml file with the extension .xml.tmp, and then rename each file to remove the .tmp part leaving the .xml until last. On startup, I only load the autosave document if I can find a .xml file and ignore .xml.tmp files. I also don’t delete the previous autosave document until the .xml.tmp file for the new document is renamed.

I guess my knowledge of what happens when you write to disk is poor. I know you can have software read/write buffers when using files, as well as OS and hardware buffers and that all of these need to be flushed. I’m confused how I can know for sure when something really has been written to disk and what I can do to protect myself. Does the renaming operation do anything to make sure buffers are flushed?

Answer 1

If the autosave file is corrupted in any way (I assume a power cut when the file is in the middle of being saved would do this?), the user will lose their work. How can I prevent such situations and do all I can to guarantee that the autosave document is in a consistent state?

To prevent loss of data due to partially written autosave file, don’t overwrite the autosave file. Instead, write to a new file each time, and then rename it once the file has been safely written.

To guard against not noticing that an autosave file has not been correctly written:

1. Pay attention to the exceptions thrown as the autosave file is written and closed in case a disc error, file system full, etc.
2. Keep a running checksum of the file as it is written and write it at the end of the file. Then when you load the autosave file, check that the checksum is there and is correct.

If the checkpointed state involves multiple files, make sure that you write the files in a well known order (without overwriting!), and write the checksum on the autosave file after all of the other files have been safely closed. You might want to create a directory for each checkpoint.

FOLLOW UP

No. I’m not saying that rename always succeeds. However, it is atomic – it either succeeds (and completes) or the file system is not changed. So, if you do this:

1. write “file.new” and close,
2. delete “file”,
3. rename “file.new” to “file”

then provided the first step succeeds you are guaranteed to have the latest “file” safely on disc. And it is simple to add a couple of steps so that you have a backup of “file” at all times. (If the 3rd step fails, you are left with “file.new” and no “file”. This can be recovered manually, or automatically by the application next time you run it.)

Also, I’m not saying that writes always succeed, or that applications don’t crash, or that the power never goes off. And the point of the checksum is to allow you to detect the cases where these things have happened and the autosave file is incomplete.

Finally, it is a good idea to have two autosaves in case your application gets itself into a state where its data structures are messed up and the last autosave is nonsensical as a result. (The checksum won’t protect against this.) Be cautious about autosaving when the application crashes for the same reason.