Hi, I'm on 4.7.1 and have been since shortly after it was released. This afternoon, when I started KMyMoney I got this error message:

File C:/Users/Mike/Documents/mike.kmy contains the old binary format used by KMyMoney. Please use an older version of KMyMoney (0.8.x) that still supports this format to convert it to the new XML based format

I used this file earlier this afternoon with no problem, and of course it has been years since I've used 0.8.x. Both automatic backups give the same error message. I found an old backup from late December, and it opens with no problem.

Help?

Try unzipping the file. If it fails to unzip, it's probably gone corrupt for some reason.
Did you notice anything last time you saved it?

Thanks for the suggestion, but no luck unzipping - unknown format or damaged file error message on the file and both auto-backups.

I didn't notice anything out of the ordinary the last time I saved. No error messages at the time.

Does the file contain any data (is the file size larger then 0)? The file should be a gzipped xml, did you try zcat or gzip?

The file's ~270kB, which is about what I'd expect by comparison to the older backup. This particular machine is on Windows so I tried Winzip after the native decompression failed. I can try zcat or gunzip tonight to see if that makes a difference.

Edited to add - it didn't make a difference.

Strange, and you say that all automatic backups (.kmy.1~, .kmy.2~ files) exhibit the same problem? Do they all have the same modification timestamp?

No, that's the thing that is really odd.

Both auto-backups exhibit the same problem, but one is from around 8 AM, one is from around 12:30 PM, and then the regular save file is around 1 PM. Those times all match up with my use of the program during the day - I did a price update on an investment, saved, and closed KMyMoney in the morning, then in the afternoon I entered a transaction, viewed some reports, saved, and closed the program. Then later in the afternoon I got the error when I started the program.

The auto-backups and the regular save file are slightly different sizes, with the file growing a few bytes each time. So that seems to match up with the activity through the day. But I'm really puzzled over how the backups are corrupted, then. The PC has no symptoms at all of a bad drive or any other kind of hardware problem.

I'm assuming the auto-backups work like this:

.kmy.1~ --> .kmy.2~
.kmy --> .kmy.1~
New modified state --> .kmy

Which seems to imply that if .kmy.2~ is corrupted, .kmy.1~ must have been corrupted earlier, and by extension .kmy must have been corrupted even earlier. But in that case, how was I able to open .kmy earlier in the day? Really weird.

.kmy.1~ --> .kmy.2~
.kmy --> .kmy.1~
New modified state --> .kmy

Yes, this is how the automatic backup is implemented in KSaveFile which is used by KMyMoney.

Which seems to imply that if .kmy.2~ is corrupted, .kmy.1~ must have been corrupted earlier, and by extension .kmy must have been corrupted even earlier. But in that case, how was I able to open .kmy earlier in the day? Really weird.

True, but if the rename process is the one that causes the corruption then the whole batch of backups might get corrupted, we only need to figure out if this was true in your case. KSaveFile uses QFile::rename which might fail but I don't see how it can corrupt the file contents.

And if my understanding from a quick glance at KSaveFile is correct, QFile::rename is also being used to do the temp file --> regular .kmy file step, so that certainly seems to fit...

I've re-entered all my transactions using my manual backup from December, so at this point the only things I've lost are changes to reports and budgets, but are there any other steps I can take to help with the post-mortem?

I don't really have any ideas about what else you can do to investigate this. Other than to analyze the binary contents of the file to see what part of it is missing (this can be tedious), is the gzip header present?

cristian.onet wrote:I don't really have any ideas about what else you can do to investigate this. Other than to analyze the binary contents of the file to see what part of it is missing (this can be tedious), is the gzip header present?

I just opened the file in a hex editor and it is 00 00 00 00 from start to finish



All three corrupted files are just 270kB of 00, so, yeah, not much to work with. Thanks anyway!