A solution

The solution we chose was to prescribe a careful, multistep method for making changes to files. In essence, one first writes one's intentions into the file, then carries them out, and finally removes the intentions. The idea is to arrange things so that if a crash occurs, the disk version of the file will appear to have either no changes, or all of the changes. This is accomplished by an agreement, among all programs that maintain the file, to perform any changes to the file that they find recorded as intentions. The recorded intentions must satisfy a number of conditions. It must be possible to repeat them, even if they have been partially, or completely, carried out; leaving the file in the intended state. (A simple list of file addresses with intended new contents would satisfy this condition.) After a crash, the file must not have a partial list of intended corrections. (A flag that signifies the presence of intended changes will satisfy this condition, if it is not turned on until the entire list of intended changes are guaranteed to be in the file.) The algorithm for making changes is:

i)

lock out other programs from the file (or files).

ii)

If the bit signalling the presence of intentions is off, go to step vii).

iii)

(A crash has occurred, we are now recovering.) Perform the intended changes.

iv)

snapshot the file(s).

v)

turn off the intentions bit.

vi)

snapshot the file containing the intentions bit.

vii)

read the file(s) to determine the desired changes.  

viii)

write a list of intended changes at some known place in the file(s).

ix)

snapshot the file(s) containing the list of intended changes.

x)

turn on the intentions bit.  

xi)

snapshot the file containing the intentions bit.  

xii)

make the changes.

xiii)

snapshot the changed file(s).

xiv)

turn off the intentions bit.

xv)

snapshot the file containing the intentions bit.  

xvi)

unlock the file(s).