[GNC] postpone reconciliation broken: ignores my changes

[Michael Hendry]

> On 8 Feb 2019, at 15:42, John Ralls <jralls at ceridwen.us> wrote:
> 
> 
> 
>> On Feb 8, 2019, at 7:31 AM, Michael Hendry <hendry.michael at gmail.com> wrote:
>> 
>>> On 8 Feb 2019, at 10:02, Michael Hendry <hendry.michael at gmail.com> wrote:
>>> 
>>>> On 8 Feb 2019, at 09:25, David T. <sunfish62 at yahoo.com> wrote:
>>>> 
>>>> I know that on my Mac, it takes some time for gnucash to actually finish the save process.  Mine is a somewhat older macbook pro with an SSD. Is it possible that you failed to wait for it to finish saving?
>>>> 
>>>> David T.
>>> 
>>> That’s what I was implying, although I would be surprised if Gnucash didn’t have a means of preventing itself from being shut down while busy doing a file save.
>>> 
>>> In any case, the orderly shutting down of the program (i.e. not involving a crash) should have included the deletion of the lock file even if it had abandoned the “Save”.
>>> 
>>> Michael
>>> 
>> 
>> Further lock file problem:
>> 
>> Yesterday evening I completed the failed reconciliation, along with a few other transactions, and quit GC before going out for a few hours at 20:30.
>> 
>> Returning home around midnight, I opened my GC file again, and tidied up a couple of loose ends, and closed down shortly afterwards.
>> 
>> Today when I tried to run GC, I got the lock file message, and this time I clicked “Quit” rather than forcing the file open.
>> 
>> I checked with Activity Monitor that there was no current instance of GC running.
>> 
>> Here is a screenshot of the Accounts folder’s most recent files:
>> 
>> https://www.dropbox.com/s/zjvogbdl885rr2d/Screenshot%202019-02-08%2015.12.05.png?dl=0
>> 
>> and the same information via the command-line:
>> 
>> | => ls -lt
>> total 84324
>> -rw-r--r--  1 michaelhendry  staff   221184  8 Feb 00:04 MDH.gnucash.tmp-ea6yhc
>> -rw-r--r--  1 michaelhendry  staff    95629  8 Feb 00:04 MDH.gnucash.20190208000345.log
>> -rw-------  2 michaelhendry  staff        0  8 Feb 00:03 MDH.gnucash.0.82823.LNK
>> -rw-------  2 michaelhendry  staff        0  8 Feb 00:03 MDH.gnucash.LCK
>> -rw-r--r--  1 michaelhendry  staff      809  8 Feb 00:01 MDH.gnucash.20190207202353.log
>> -rwx------  2 michaelhendry  staff  1136826  7 Feb 20:23 MDH.gnucash
>> -rw-r--r--  1 michaelhendry  staff      853  7 Feb 20:23 MDH.gnucash.20190207202200.log
>> -rwx------  2 michaelhendry  staff  1136826  7 Feb 20:23 MDH.gnucash.20190208000443.gnucash
>> -rw-r--r--  1 michaelhendry  staff    23810  7 Feb 20:22 MDH.gnucash.20190207185926.log
>> -rwx------  1 michaelhendry  staff  1136752  7 Feb 20:22 MDH.gnucash.20190207202348.gnucash
>> -rwx------  1 michaelhendry  staff  1136766  7 Feb 18:59 MDH.gnucash.20190207202153.gnucash
>> 
>> There is no corresponding crash report, so I conclude that GC has failed to tidy up properly before closing.
> 
> Do you remember how you did the save last night? IOW did you click the save button, wait until the save was finished, and select GnuCash>Quit from the menu or type Cmd-Q and then select "Save before quitting" from the dialog box, or perhaps click the save icon and then immediately type Cmd-Q?
> 
> Regards,
> John Ralls

PS Looking at the log files, I’m reminded that a number of scheduled transactions took place during the session. Inspecting these it seems that each one is recorded four times - here’s an example extracted from the larger of the two log file:

===== START
B	aefe075a22d466826d4735afb8159c08	cd4cb60c1e5a5294eb4e7d2623dbaebe	2019-02-08 00:03:46 +0000	2018-08-05 12:20:04 +0100	2018-08-05 11:59:00 +0100	9768413066e3e0d1272ba7839ea5f1cc	b0e28c7d097d448b29f193895c973d63		Amazon Prime Subscription				n	0/1	0/100	1970-01-01 01:00:00 +0100
B	aefe075a22d466826d4735afb8159c08	f9d8cacc6b99135677ccc97ce6f4887d	2019-02-08 00:03:46 +0000	2018-08-05 12:20:04 +0100	2018-08-05 11:59:00 +0100	9768413066e3e0d1272ba7839ea5f1cc	b0e28c7d097d448b29f193895c973d63		Amazon Prime Subscription				n	0/1	0/100	1970-01-01 01:00:00 +0100
===== END
===== START
R	aefe075a22d466826d4735afb8159c08	cd4cb60c1e5a5294eb4e7d2623dbaebe	2019-02-08 00:03:46 +0000	2018-08-05 12:20:04 +0100	2018-08-05 11:59:00 +0100	9768413066e3e0d1272ba7839ea5f1cc	b0e28c7d097d448b29f193895c973d63		Amazon Prime Subscription				n	0/1	0/100	1970-01-01 01:00:00 +0100
R	aefe075a22d466826d4735afb8159c08	f9d8cacc6b99135677ccc97ce6f4887d	2019-02-08 00:03:46 +0000	2018-08-05 12:20:04 +0100	2018-08-05 11:59:00 +0100	9768413066e3e0d1272ba7839ea5f1cc	b0e28c7d097d448b29f193895c973d63		Amazon Prime Subscription				n	0/1	0/100	1970-01-01 01:00:00 +0100
===== END
===== START
B	aefe075a22d466826d4735afb8159c08	cd4cb60c1e5a5294eb4e7d2623dbaebe	2019-02-08 00:03:46 +0000	2018-08-05 12:20:04 +0100	2018-08-05 11:59:00 +0100	9768413066e3e0d1272ba7839ea5f1cc	b0e28c7d097d448b29f193895c973d63		Amazon Prime Subscription				n	0/1	0/100	1970-01-01 01:00:00 +0100
B	aefe075a22d466826d4735afb8159c08	f9d8cacc6b99135677ccc97ce6f4887d	2019-02-08 00:03:46 +0000	2018-08-05 12:20:04 +0100	2018-08-05 11:59:00 +0100	9768413066e3e0d1272ba7839ea5f1cc	b0e28c7d097d448b29f193895c973d63		Amazon Prime Subscription				n	0/1	0/100	1970-01-01 01:00:00 +0100
===== END
===== START
R	aefe075a22d466826d4735afb8159c08	cd4cb60c1e5a5294eb4e7d2623dbaebe	2019-02-08 00:03:46 +0000	2018-08-05 12:20:04 +0100	2018-08-05 11:59:00 +0100	9768413066e3e0d1272ba7839ea5f1cc	b0e28c7d097d448b29f193895c973d63		Amazon Prime Subscription				n	0/1	0/100	1970-01-01 01:00:00 +0100
R	aefe075a22d466826d4735afb8159c08	f9d8cacc6b99135677ccc97ce6f4887d	2019-02-08 00:03:46 +0000	2018-08-05 12:20:04 +0100	2018-08-05 11:59:00 +0100	9768413066e3e0d1272ba7839ea5f1cc	b0e28c7d097d448b29f193895c973d63		Amazon Prime Subscription				n	0/1	0/100	1970-01-01 01:00:00 +0100
===== END

I don’t know what the significance of “B” and “R” is in the first column, but the pairs of lines appear to be record the guids of the each transaction and the accounts the split refers to. I don’t suppose the appearance of Unix zero time (1970-01-01 01:00:00 +0100) at the end of each line is of any significance.

Michael