[Tutor] Corrupt file(s) likelihood and prevention?

[boB Stepp]

While reading Alan's response I found myself having a sense of déjà
vu.  Looking back at last year's Tutor archives I found
https://www.mail-archive.com/tutor@python.org/msg80574.html where I
was asking about the pluses/minuses of storing calculated values
versus recalculating them upon a rerunning of a program.  The topic of
data corruption came up there.  Alan's responses then and more
pointedly now that _eventually_ data corruption will happen is
bothersome in my mind even though he pointed out that this, in his
experience, was rarely a problem.  But ...

On Fri, Jan 31, 2020 at 5:20 PM DL Neil via Tutor <tutor at python.org> wrote:

> So, if I've interpreted your interest correctly, the pertinent part of
> that (perhaps less apparent in your question) is: what can we do about
> the risk  of corruption, when files which may have been updated, have
> not been/cannot be, closed properly?

This along with other possible sources of problems seems to demand
some sort of defensive programming.  Should every file in a program,
both data files and source code files have an associated checksum?  I
mentioned that one of the applications I use at work makes extensive
use of checksums.  Every file in the application I have ever opened
ends in a checksum value.  The other mentioned solution for data is to
use a robust database application to store the data which presumably
manages, as best as these possibilities can be managed, prevention of
data corruption.  But what about the source code itself?  Maybe a
corrupt file will crash, but maybe it won't and will subtly lead to
erroneous behaviors?  I don't know; I'm speculating at this point.

But even if corruption is detected, unless actually retrievable
backups exist, per Alan, one is stuck in one's tracks!

-- 
boB