Maybe I'm not understanding this new interface, but every time I open one of my files in version 3.4, it appears with an asterisk in the title bar, and when I attempt to close GnuCash it asks me to Close Without Saving, even though I have made no changes to the file. This behavior is persistent until I click the Save button, as though the new version was waiting for me to upgrade each file. I think it would be better to respect the user's understanding of whether the file is already saved or not.
That's more than likely because of a repair function we call a "scrub". When we fix a bug in GnuCash we sometimes find that it has introduced errors in the data. When we do we add a "scrub" function as part of loading the file to correct the errors. The most recent one, added in GnuCash 3.4, removes superfluous slots for color in accounts when no color is set. I'll leave this open as it would be helpful to pop a dialog box explaining why the data needs to be saved when the user hasn't done anything to it.
I'm having a similar problem now in 3.5-27 where I open an old file and it appears normal until I expand or collapse any placeholder in the accounts list, and then the file switches to unsaved. Is this the same bug?
Is the "old" file one that you haven't opened with 3.5 and re-saved before? If so then it's a combination of this bug and a new one where the save button doesn't light up until something else causes a redraw. If it's a file that you have opened before then it's a new problem. Changing the window appearance shouldn't make the book dirty.
The particular file I tested was dated 02/02/2019 and does not appear to be in XML format anymore. Begins with 1f 3c 08 00 00 00 00 00 00 0a.
You probably turned on compression in Preferences>General. It's gzip and 7Zip can unzip it for you.
Indeed. Is there anything version-related you need from the XML?
UNfortunately we don't write version information into the data file so there's no way to recover anything useful from that. Since you apparently started using 3.4 around the first of the year it's presumably a file you'd opened before.
If you like, I could re-save the file and see if the bug goes away. I was just curious if there is something the program looks for in an "old" file that triggers the scrub.
No harm in trying, GnuCash always renames the old XML file and writes a new one.
Running 3.5-126 now it's back to always unsaved instead of waiting for a redraw. I opened that same file, saved it, and then the symptoms went away again.
Good, I guess. Just to make sure I'm clear, you opened the file from 2 Feb and it wanted to be saved so you did and now when you open it it doesn't want to be saved anymore, right?
Correct. So is it finding version info in the file or is it tracking paths to updated files?
Neither, it's examining the data stream as it loads the file. I ran a test by loading an old file and saving it, then ran a programming tool called "diff" on the backup and the new file. It shows all of the changes in the file. The changes were the removal of an account slot called "color-key" having value "not set" and creating a slot on the book, "remove-color-not-set-slots", recording that this was done. That scrub was created in https://github.com/Gnucash/gnucash/commit/5c524c31b2c953087b70305c24547960e0d5e585.
My file from 2/2/2019 already had those changes. I will diff them and see what's going on here.
Two things: - <slot:key>book</slot:key> - <slot:value type="frame"> - <slot> - <slot:key>tax_US</slot:key> + <slot:key>tax_US</slot:key> And then later in the file it looks like every <ts:date> value has been revised.
The test file I used didn't have any tax_US keys... and I imagine none of my regular ones would either because I don't use the txf report. Just another scrub from 7d0adfd0c6. The date change is a side effect. It doesn't affect the internal representation at all, it just gets rid of noise in the file and saves a tiny amount of work when parsing it.
