Actually there seems to be something similarly odd going on with my
3.4 system on Ubuntu. When I open GC it immediately creates a 90k log
file with loads of scheduled transaction entries, none of which do (or
should) actually make it to the register. So for instance I see
===== START
B 4edff70199ce6659c8739ee541adb772
aeb2ee83f309c966cbb9fb8c9d92e6f5 2019-02-08 22:19:07 +0000
2009-07-11 12:26:57 +0100 2009-07-11 11:59:00 +0100
b8780cf5f2ce52e0e880ae32bfac2f95 8d72c8ce9830cd1232ce606f3ea906fb
RSPB n 0/1 0/100 1970-01-01 01:00:00
+0100
B 4edff70199ce6659c8739ee541adb772
29942dc723b0c19cd47c078e62811a3e 2019-02-08 22:19:07 +0000
2009-07-11 12:26:57 +0100 2009-07-11 11:59:00 +0100
b8780cf5f2ce52e0e880ae32bfac2f95 8d72c8ce9830cd1232ce606f3ea906fb
RSPB n 0/1 0/100 1970-01-01 01:00:00
+0100
===== END
===== START
R 4edff70199ce6659c8739ee541adb772
aeb2ee83f309c966cbb9fb8c9d92e6f5 2019-02-08 22:19:07 +0000
2009-07-11 12:26:57 +0100 2009-07-11 11:59:00 +0100
b8780cf5f2ce52e0e880ae32bfac2f95 8d72c8ce9830cd1232ce606f3ea906fb
RSPB n 0/1 0/100 1970-01-01 01:00:00
+0100
R 4edff70199ce6659c8739ee541adb772
29942dc723b0c19cd47c078e62811a3e 2019-02-08 22:19:07 +0000
2009-07-11 12:26:57 +0100 2009-07-11 11:59:00 +0100
b8780cf5f2ce52e0e880ae32bfac2f95 8d72c8ce9830cd1232ce606f3ea906fb
RSPB n 0/1 0/100 1970-01-01 01:00:00
+0100
===== END
===== START
B 4edff70199ce6659c8739ee541adb772
aeb2ee83f309c966cbb9fb8c9d92e6f5 2019-02-08 22:19:07 +0000
2009-07-11 12:26:57 +0100 2009-07-11 11:59:00 +0100
b8780cf5f2ce52e0e880ae32bfac2f95 8d72c8ce9830cd1232ce606f3ea906fb
RSPB n 0/1 0/100 1970-01-01 01:00:00
+0100
B 4edff70199ce6659c8739ee541adb772
29942dc723b0c19cd47c078e62811a3e 2019-02-08 22:19:07 +0000
2009-07-11 12:26:57 +0100 2009-07-11 11:59:00 +0100
b8780cf5f2ce52e0e880ae32bfac2f95 8d72c8ce9830cd1232ce606f3ea906fb
RSPB n 0/1 0/100 1970-01-01 01:00:00
+0100
===== END
===== START
R 4edff70199ce6659c8739ee541adb772
aeb2ee83f309c966cbb9fb8c9d92e6f5 2019-02-08 22:19:07 +0000
2009-07-11 12:26:57 +0100 2009-07-11 11:59:00 +0100
b8780cf5f2ce52e0e880ae32bfac2f95 8d72c8ce9830cd1232ce606f3ea906fb
RSPB n 0/1 0/100 1970-01-01 01:00:00
+0100
R 4edff70199ce6659c8739ee541adb772
29942dc723b0c19cd47c078e62811a3e 2019-02-08 22:19:07 +0000
2009-07-11 12:26:57 +0100 2009-07-11 11:59:00 +0100
b8780cf5f2ce52e0e880ae32bfac2f95 8d72c8ce9830cd1232ce606f3ea906fb
RSPB n 0/1 0/100 1970-01-01 01:00:00
+0100
===== END
Should those be there?
Colin
On Fri, 8 Feb 2019 at 22:02, Michael Hendry <[email protected]> wrote:
>
> > On 8 Feb 2019, at 17:26, John Ralls <[email protected]> wrote:
> >
> >
> >
> >> On Feb 8, 2019, at 8:28 AM, Colin Law <[email protected]> wrote:
> >>
> >> On Fri, 8 Feb 2019 at 15:31, Michael Hendry <[email protected]>
> >> wrote:> ...
> >>> | => 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.
> >>
> >> That looks odd. Notice that the last successful save was 7 Feb 20:23.
> >> Then it appears that GC was started at 8 Feb 00:03, a log file of 95k
>
> Actually, the first file was modified on 8th Feb at 00:01, followed by the
> lock file at 00:03.
>
> The MDH.gnucash.tmp-ea6yhc file isn’t a text file like the others, so I
> suspect that it’s part of the compression process that eventually results in
> a new MDH.gnucash file.
>
> >> bytes was created (which seems large) but the results of that work
> >> were not saved. I don't know, but it may be that the file
> >> MDH.gnucash.tmp-ea6yhc is the result of the first half of the save
> >> before it is compressed and the files renamed but I don't know. How
> >> you could get a log file that large in one minute I don't know. I see
> >> you have posted some of the contents and suggested they don't look
> >> right.
> >
> > Scheduled transactions is how he could get 95K of log file in milliseconds.
> >
> > Good eye, noticing the temp file: The save failed for some reason and left
> > GnuCash in a state where it quit without removing the lock. It's too bad
> > that we overwrite trace files on MacOS. It would be useful to see if
> > anything got logged about the save failing.
> >
> > I think it's time to open a bug on this.
> >
> > Regards,
> > John Ralls
>
> Thanks, John.
>
> Is it up to me to initiate this?
>
> Michael
_______________________________________________
gnucash-user mailing list
[email protected]
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.
