NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Then again, keeping an external hash in another file may allow one to determine whether the data, or the hash were modified.
The benefits derive, IMO, from the point of view of data source. If you control the data, and you're concerned about programmatical mods causing problems, the external method has benefits.
If you're concerned about data security and integrity, the former approach, allowing you to simply say, "It's bogus, let's attempt to get it from another source," has promise.
For simplicity, I'd agree that a separate file approach is an acceptable one.
gerry Russ Rew wrote:
I wrote:I think there are some good reasons to keep hashes such as MD5 or SHA-1 external to files they are intended to check, rather than embedded in the files: - If the digest is external, then something that corrupts the file might also corrupt the digest.which makes no sense. What I meant to say was - If the hash is embedded in the file and doesn't agree with the file contents, it's not clear whether the file or the hash or both were corrupted. This is fairly minor, since a mismatch would tell you not to trust the data in any case. But I still think keeping the hash separate from the original file makes it easier to compute. --Russ
-- Gerry Creager -- gerry.creager@xxxxxxxx Texas Mesonet -- AATLT, Texas A&M University Cell: 979.229.5301 Office: 979.458.4020 FAX: 979.847.8578 Page: 979.228.0173 Office: 903A Eller Bldg, TAMU, College Station, TX 77843
netcdfgroup archives: