in reply to Atomic Config Updater with History?
Atomic IO is as rare as rocking horse do-do.
If you write to a local text file, your blob may (will frequently) cross a disk block boundary. Therefore, the start of the blob may get written to disk as a part of one 4k disk block; and the end of it as part of another. If the machine goes down between the two writes, non-atomic.
Compound that with the fact that all modern OSs use transparent file caching. Even once you've "written to disc", you've often only written to the cache. and if something crashes, what you think you've already written can get lost.
And unless your file-system allows you to make your log file contiguous, it is quite possible that due to write reordering, that the second block in the first scenario might get written before the first. And if the interrupt occurs at the inappropriate time, you have the end of a blob but not it's start.
If you are prepared to bypass Perl & your CRT lib, then your OS might provide write-thru file handling APIs. If you use these, synchronous IO, and write 4K blocks every time, you can achieve something approaching atomic. But still, disk heads do occasionally crash mid-block.
If your file is on a remote system, the transmission protocol (TCP/IP or whatever) is free and will frequently aggregate and/or break up writes in order to form transmission packets optimised for the comms fabric. And that can happen multiple times if the transmissions cross fabric boundaries (eg. cat5 to fiber and back; or 54Mb/s to 1Gb/s; etc) in the course of it's journey.
The point is, that if you really need total reliability under any (well most at least) circumstances, then you need to stop thinking "atomic" and start thinking Two Phase Commit.
Personally, I think a transactional DB is your best bet. INSERT the message saying what you are about to do; do it; then commit.