Re: [Gnumed-devel] Corrupt database

[Karsten Hilbert]

> Can it be assumed that if the schema can be successfully queried, and that it 
> matches the hash of the reference fingerprint, that the file is not corrupted?

No, and in fact, there are many files making up one database.

> Would it make sense to automate this check of fingerprints as part of the 
> backup procedure?

Refuse to back up and/or restore if there is a database mismatch ?

> This might involve to keep, in the backup directory, a copy of whatever is 
> the desired reference fingerprint.

What use do you have in mind ?  One thing I can imagine is including
"corrupted_schema" in the backup filename if so.

> The result of the script could append a line onto the end of a backup file say
> 
>       fingerprint.check
> 
> with
> 
>       datetime version_current hashvalue_current version_reference 
> hashvalue_reference
>       Tue 28 May 2013 19:01:02 PDT gnumed_v18 
> a0f9efcabdecfb4ddb6d8c0b69c02092 gnumed_v18 a0f9efcabdecfb4ddb6d8c0b69c02092
>       Wed 29 May 2013 21:01:02 PDT gnumed_v18 
> a0f9efcabdecfb4ddb6d8c0b69c02092 gnumed_v18 a0f9efcabdecfb4ddb6d8c0b69c02092
>       Thu 30 May 2013 20:04:09 PDT gnumed_v18 
> z6f7a1428e7c83f4bf638c3a1146e93s gnumed_v18 a0f9efcabdecfb4ddb6d8c0b69c02092

What would be the benefit ?  Given that the client verifies the hash every 
single time
it is started I dare say the user would learn of mismatches very quickly w/o 
keeping
a log of hashes.

Karsten