[GNC] GC 3.4 quit aborts file save process (was Re: postpone reconciliation broken: ignores my changes)

Sun Feb 10 09:47:54 EST 2019

First test:
Windows 7 Pro 64 bit on Dell Precision 7510 laptop w/ 24467 MB RAM
installed, approx 16600 MB free
GnuCash 2.6.19
7,126 KB XML compressed data file on NAS connected via Ethernet

Before I ran this documented test on a fresh copy of my 2 day old current
data file I tried opening GnuCash and using Ctrl-W after clicking Save.
GnuCash completed the save but did not hold the Ctrl-W keystroke so it did
not respond after completing the save. After the save was completed I again
clicked Ctrl-W and GnuCash closed the current window.  Then I closed
GnuCash and deleted the data file, backup and logs.  I replaced them with a
new copy of my 2 day old current data file.

File opening takes roughly 2 minutes with scads of account windows to open
and several reports to generate, 6 SX's create automatically.  This
generated about 7,000 KB initial log file.
I reviewed the new transactions and accepted them with one minor text edit
in one transaction number field.
Then I clicked Save followed immediately by Ctrl-Q several times.  There
was no visual indication whether the Ctrl-Q's took, I think that they were
ignored, so I clicked the red X in the upper right corner of the GnuCash
window.
Now I could see some flickering near the last curser position in the window
as the save progress bar progressed at the bottom, and  GnuCash  closed
after increasing the initial log file to 21,134 KB, saving a backup,
creating another 48 KB log, renaming these files and deleting the LCK file.

I want to set up a test of release 3.4 but I need to review all the prep
necessary to be able to return to 2.6.19 after the test, so that will take
a while.  I also need to be able to return to 2.6 17 in Linux on a
different machine with my current data file.

David Carlson

On Sun, Feb 10, 2019 at 7:34 AM Colin Law <clanlaw at gmail.com> wrote:

> I have tried Save and immediately shutdown in Ubuntu 18.10 (Gnucash
> 3.4) and I can't make it fail.  It is not possible to select File >
> Quit while it is saving as the menus are disabled and if I click the
> cross to shut the window down then nothing happens till the save has
> completed and it then shuts down.
>
> Colin
>
> On Sun, 10 Feb 2019 at 12:16, David Carlson <david.carlson.417 at gmail.com>
> wrote:
> >
> > I can try to interrupt the shutdown in Windows, but the xeperiment would
> > have limited value since I have not set up a 3.4 installation yet.  I am
> > usually running 2.6.17 in Ubuntu right now and there I am reasonably sure
> > that instance cannot be interrupted except by catastrophic OS or power
> > failure.  I will have some time in a couple of hours.
> >
> > David Carlson
> >
> > On Sat, Feb 9, 2019, 10:33 PM John Ralls <jralls at ceridwen.us wrote:
> >
> > > David,
> > >
> > > Can you reproduce the interrupted save on Windows? I haven't tried
> that or
> > > Linux yet, though I was able to easily do so on Mac. The quit code
> path is
> > > a bit different on Mac from the others because the OS handles the
> event and
> > > sends a notification to the app rather than the app handling the event
> > > directly.
> > >
> > > Regards,
> > > John Ralls
> > >
> > >
> > > > On Feb 9, 2019, at 7:15 PM, David Carlson <
> david.carlson.417 at gmail.com>
> > > wrote:
> > > >
> > > > I am still using release 2.6.17 as I have previously mentioned in
> other
> > > contexts.  I believe that this is a change
> > > >  from the behavior of the 2.6.x series.  In that series I do not
> think
> > > it is possible to interrupt the orderly shutdown process including a
> > > complete file save, backup and lock file removal when using the default
> > > data file format.
> > > >
> > > > This is even more critical if the process takes a long time due to
> > > various circumstances including large file size or leaving several open
> > > windows and/or reports open when closing the file.
> > > >
> > > > David Carlson
> > > >
> > > > On Sat, Feb 9, 2019 at 6:01 PM John Ralls <jralls at ceridwen.us>
> wrote:
> > > >
> > > >
> > > > > On Feb 9, 2019, at 3:38 PM, Michael Hendry <
> hendry.michael at gmail.com>
> > > wrote:
> > > > >
> > > > >> On 9 Feb 2019, at 23:16, John Ralls <jralls at ceridwen.us> wrote:
> > > > >>
> > > > >>
> > > > >>
> > > > >>> On Feb 9, 2019, at 3:07 PM, Michael Hendry <
> hendry.michael at gmail.com>
> > > wrote:
> > > > >>>
> > > > >>> I’ve been experimenting with the timing of Gnucash->Quit after
> > > clicking Save.
> > > > >>>
> > > > >>> There is an activity indicator after Save is clicked, which
> > > disappears when the mouse is moved away from the Save button, which
> makes
> > > it look as though the process is complete.
> > > > >>>
> > > > >>> If Gnucash->Quit is clicked promptly after Save, it appears that
> the
> > > process of saving is aborted leaving the .LCK and .LNK files, a log
> file,
> > > and a binary file called something like MDH.gnucash.tmp-gkUdOJ.
> > > > >>>
> > > > >>> The connection I had made with the extensive reconciliations I
> had
> > > made (sometimes including Postpone) was irrelevant, as this will happen
> > > even if no reconciliation has taken place.
> > > > >>>
> > > > >>> The Save button is greyed out when the file is first opened, but
> a
> > > trivial change to an existing transaction is sufficient to make it
> > > functional.
> > > > >>>
> > > > >>> I don’t believe this intended behaviour, so I plan to report it
> as a
> > > bug, once I work out how to do it!
> > > > >
> > > > > That last line should have started:
> > > > >
> > > > > “I don’t believe this is…”
> > > > >
> > > > > but you obviously worked that out!
> > > > >
> > > > >>
> > > > >> Indeed, it's not intended behavior, and it seems consistent with
> what
> > > you reported earlier. Good job!
> > > > >>
> > > > >> Regards,
> > > > >> John Ralls
> > > > >>
> > > > >
> > > > > Thanks, John.
> > > > >
> > > > > You will probably have received a copy of the bug report.
> > > > >
> > > > > I mentioned the large number of apparently redundant lines in the
> .LOG
> > > files - but I’m not sure if this is meant to happen.
> > > >
> > > > I think the logging is meant to happen. The multiple creation and
> > > rollback isn't and might be part of the cause of the slow shutdown.
> > > >
> > > > For everyone else following along, the bug is
> > > https://bugs.gnucash.org/show_bug.cgi?id=797098. We'll continue the
> > > discussion there.
> > > >
> > > > Regards,
> > > > John Ralls
> > > >
> > > > _______________________________________________
> > > > gnucash-user mailing list
> > > > gnucash-user at gnucash.org
> > > > To update your subscription preferences or to unsubscribe:
> > > > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > > > If you are using Nabble or Gmane, please see
> > > https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> > > > -----
> > > > Please remember to CC this list on all your replies.
> > > > You can do this by using Reply-To-List or Reply-All.
> > >
> > >
> > _______________________________________________
> > gnucash-user mailing list
> > gnucash-user at gnucash.org
> > To update your subscription preferences or to unsubscribe:
> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> > -----
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
>