File signatures??

[John Ralls]

> On Jun 30, 2017, at 11:06 AM, max at hyre.net wrote:
> 
>   Dear Matt:
> 
>> The problem is that the recovery operation (using
>> Testdisk/Photorec) results in files and file fragments
>> that may or may not be correctly identified by file
>> extensions.
> 
>   It sounds like what you want is a magic number (file-format ID: https://en.wikipedia.org/wiki/File_format#Magic_number) for .gnucash files.  Looking at my file it appears that ``<gnc-v2'' starting at the 41st character in the file whould do it.  (I presumee the `2' in ``-v2'' is a version number, and could change at some future date, but for now that's not a problem.)
> 
>   It would be nice if the recovery program lets you add to the file-ID list, otherwise you're back to grep.  I hope that it recognizes gzipped files (possible GNUCash files, compressed), but if not you want to look for the first two characters = 0x1f 0x8b.  Of course, then you'll have to unzip them to see whether they're really what you want.  :-/
> 
>   Gurus:  Is this right?  For future-proofing, can we assume the magic number will always be in position 41?  Is there an actual, designated, magic number for GNUCash files somewhere?
> 
>   Hope this makes sense/helps...

No, one can’t assume that the magic number will always be in position 41. Don’t even assume that the primary data file will always be optionally gzipped XML, because it won’t. It’s not going to change for the next version, but it will eventually change to a SQL database with XML as a format for making backups.

Furthermore, building facilities into the file structure to make recovery from catastrophic disk failure is the wrong answer. The right answer is to make backups. It should be an automatic process, the backups should at the very least go on a separate physical disk and to a cloud service like Dropbox.

If *anyone* reading this doesn’t have automatic backup set up, it’s your project for the day. Don’t put it off!

Regards,
John Ralls