[wfc] Next: Checksum proposal

[Rob Seaman]

Bob says:

> In the past I have expressed my reservations about the checksum proposal,
> i.e., whether it is really necessary.

Some things are like vitamins - they're just good for you.

> Computer systems have so much inherent error checking built in to them
> that I wonder if adding our own additional check really adds anything.

"Built in"?  That's precisely what we're talking about.  How to build
checksum protection into FITS.  The reality is that error checking is
often an oversight or manual addition, even at the system level.

> I also worry a bit about people making manual changes to FITS files,
> which invalidate the checksum but in fact do not affect the integrity
> of the file.  And I worry about FITS files being manipulated by
> programs that do not update the checksum, yet the files are perfectly
> valid.

We're seeking official recognition of the checksum proposal precisely
to minimize such situations.  The checksum keyword usage described
in the proposal is perfectly valid FITS - and has been in use since
1994.  NOAO has about 3,000,000 FITS files containing checksums.
Other sites also have extensive data stores.

The proper behavior for a program that modifies FITS files but does not
update checksums is to delete the checksum/datasum keywords.  How will
this behavior be promulgated if the checksum proposal is ignored?

> I checked with the HST archive staff about this also, and there was
> not a lot of enthusiasm.  They said that the few data corruption
> problems we've had would probably not have been avoided, even with
> a FITS checksum.

Enthusiasm?  Get real!  This is a checksum - it's supposed to be boring.

The point of a checksum is not to avoid data corruption - it's to
improve the chances of detecting such when it occurs.

Rob Seaman