Overwrite document file

Question

I am developing a document-based desktop application that writes a rather large and complex file to disk when the user saves his document. What is the best practice to prevent data corruption? There are several things that can happen:

The save process may fail halfway, which, of course, is a serious application error, but in this case it is better to leave the old file than a damaged half-written file. The same problem will occur if the application is terminated for any other reason halfway through the file entry.

The most reliable approach I can come up with is to use a temporary file when saving and replace only the original file after successfully creating a new file. But I find that there are several operations (creating tempfile, saving to tempfile, deleting the original, moving tempfile to the original), which may or may not be unsuccessful, and I get a rather complicated mess of try / catch statements to handle them correctly.

Is there a best practice / standard for this scenario? For example, is it better to copy the original to a temp file and then overwrite the original than save it in a temporary file?

Also, what is the reason for the state of the file in the document-based application (in windows)? Is it better to leave the file open for writing in the application until the user closes the document, or simply closes in the open file and closes it again? Pros and cons?

Answer 1

Usually the file shuffle dance happens like this: the goal is to file.txt contain the new data:

• Write to file.txt.new
• Move the .txt file to the .txt.old file
• Move file.txt.new to .txt
• Delete the .txt.old file

At any time, you always have at least one valid file:

• If only the .txt file exists, you have failed to start writing file.txt.new
• If file.txt and file.txt.new exist, you probably did not work while recording. file.txt must be a valid old copy. (If you can check the files, you can try uploading a new file - this may be a bad move)
• If file.txt.old and file.txt.new exist, the second move operation failed. You can use any file, depending on whether you want new or old
• If file.txt.old and file.txt exist, the delete operation failed. Again, you can use any file.

It is assumed that you are on a file system with an atomic move operation. If this is not the case, I believe that the procedure is the same, but you need to be more careful in the recovery procedure.

Answer 2

Answering the last question:

If we are talking here about rather complex and large files, I would personally decide to lock the file, since during the reading I might not need to upload all the data for viewing, but only the one who needs it now.

Firstly:

• Always save the temp file.
• Replace the old one with a new one if this fails, given the fact that your application is a document management application, your main goal has failed, therefore the worst case, but you have a new temp file. Thus, this error can close your application and reopen (critical error), when you re-open the control, if there is a temporary file, if so, start data recovery, more or less similar to VS execution in case of failures.

Answer 3

Creating a temporary file and then replacing the original file with a temporary file (the latter is a cheap operation in terms of I / O) is the mechanism used by the MFC document storage classes. I NEVER saw him fail. Users also did not report such problems. And yes, then the documents were large (they were complex, but it had nothing to do with I / O).