CF updates its destination file "in-place"

[jphickey]

The CF application, when receiving files, will open the destination file as indicated in the Metadata PDU and immediately start writing data to it, thereby overwriting any data that was previously in the file at that position.

This can be dangerous, because the file transfer may not ultimately succeed. For instance, CRC errors may occur, or part of the transfer might get lost. But once data has been clobbered, there is no way to "undo" and restore the original data -- its gone. So now the user has a situation where neither the new file nor the original file are valid - the file is just corrupt now.

It is often desirable to write data to a temporary file first, let the transfer run to completion (storing ALL data in the temporary file), and then rename the file to its final/correct filename only after the final CRC and size checks have passed and the data is known to be good (or at least to the extent that CF can verify it).

In fact, this is the only way to safely update application binary object (.so files) on many targets, since the text/rodata memory pages may be mmap'ed directly to the file on disk. If these are updated in place, and the file is an actively-running application, then the running code will immediately "see" the modifications, and likely crash/segfault depending on what it was doing at the time.

Recommendation here is to ALWAYS use a temporary file to store incoming data, never overwrite existing files until final validations have occurred. This will also avoid some of the special logic that only handled corner cases (see issue #131) by making that more the norm than the exception.