Hi Michael,

Elog purists, look away now.

There is an "official" way to do this, which is to have fields for entry date (so can be in the past), but the yymmdda.log file will be of the date and time you make the entry.  This is in the offical documentation.

If you are not bothered by the ID number being out of sequence (and elog does not really mind, although it occasionally throws a hissy fit/throws its toys out of the pram, which a restart sorts out), but you are one who wants the date of the entry in the log file to also be in the past, skipping the entry date fields issue, it's perfectly do-able.  So long as you can access the yymmdda.log files.

What I, and some others, do is to create a new entry now (for ease, the first entry of the day, but that's not critical), then go to the log files, and with an editor open today's file, find the entry, and edit the day, date and if necessary time; I always set the time as post 22:00, as code for an edited late entry.  I also then cut-and-paste the entry into the log file for the day it should have been entered in (creating it if necessary, in linux make sure the permissions are correct, specifically the user).

If you have attachments, and want those also to reflect the date, you'll need to edit the Attachments section of the elog entry headers (format is obvious), and also rename the attachment files in the directory.

I've not tried an ID number being other than an integer, I guess it would not work.  ID numbers not being in sequence with the date doesn't seem to matter.  Messing with ID numbers can have a number of consequences, such as elog running away, burning CPU time etc (looking for a previous entry that does not exist), or rogue listings of a entry ID no./# 0 (looking for a later entry that does not exist).

One caveat; I use Linux, and on elog 2.9.2.  Later elogs and Windows may have a different reaction to what I've written above.

Elog purists can now look again.

As a regular elog (ab)user, I have seen this behaviour from time to time.  So far as I recall, the cause actually is that a normal entry is looking for the entry in the "Reply to" field of the normal entry in the yymmdda.log file.  When that entry does not exist, then I see a duplicate line of an entry with entry "#0", in emboldened black type.  I did have a screenshot, but cannot find it for now. 

A quick (relative term, that) search usually finds the entry which references the missing "Reply to" line, and editing that, all is well.  I'm not sure how this can happen, but it does.  NB, I'm still on elog 2.9.2 so I don't know how the draft facility works and possibly enhances the possibility of this issue.

Note that this is different to the case (rather more frequent) where the entry in  the "In reply to" field is missing.  This causes elog to go into a continuous loop and only the strongest measures  ("kill -9 xxxx in linux) will break this out.  This can happen more frequently as if you delete a thread with a large number (>40?) of entries, elog crashes, but more importantly, hasn't finished the job.  Clicking on the remenents of the thread (which are usually the later entries) causes the endless loop.

I too have this as an occasional issue, although in my case due to a dodgy pointer.  I too manually delete the entries.

Interestingly, it gives double entries - and thus the start of a branch - even in logbooks were branches are not allowed.

May I slip my vote in for this, especially if it would allow more than 100 attributes (the default, and I do know how to increase it).

I even considered cutting that into two groups,. the first being words like "New", "Re-" and the second being actions.  Clunkey and binned.

Hi Lesley,

Perhaps I can restate Stefan's comment.  The data structure of an elog entry, or indeed the structure of daily file(s) for any particular logbook has not changed between v2 and v3.  What has changed is the directory structure.  A set of sub-directories (named by calendar years) are added to each logbook, and all entries/files for any said calendar year moved into the directory for that year.  It gave me a shock the first time I tried using v3 elog, I wondered what it was doing  - it was the auto-conversion to v3 file structure.  I had to convert it all back to v2 file structure, so as to continue to use v2.9.2, so I'm pretty sure there is no change to the data structure within any file, else I think the older elog would kick up a fuss.  As an elog (ab)user, I've plenty of practice with the struture of the data files.

(There was a data structure change between v1 and v2 elog).

Hi,

I've had problems in the past due to a dodgy pointer creating branches despite a "No branches" in the configuration file.  It would be very interesting to see what the 200428a.log file looks like with these entries: in the screenshot they appear to be shown in time order, but do the "Reply to" and "In reply to" liknes in each entry (in the .log file) show a linear progression through the entires, a branch or indeed this same order as the screenshot.  If the duplicated entry sequential to 5657 (i.e 5658) then I would suspect something akin to my pointer's double click when I only made a single click, so fast that then second entry were created before the "No branches" checking part of the program had been reached.  Not so sure about such an event here unless entry 5658 were already open but not closed?

Regards,

David.

Hi Frank,

There are two interesting points about the log file. 

1.  Entry 5658 is timestamped later than 5659, but is earlier in the entry list.  It also is "In Reply to" 5659. despite 5659 having not been written (or at least timestamped) at the time that 5658 is.  Might this be a feature of the draft function?  I've not upgraded my elog for a long time now so my version doesn't have the feature - so I cannot test the idea of more than one entry being worked upon at the same time.

2.  Entry 5657 says it is "In Reply to" 5656, but entry 5656 does not reference 5657 in the "Reply to" line, as it should   Again, this might be a feature of the draft function

Could someone be confusing a draft entry with a real one?  Or two attempts to make an entry?

On the idea of large number of entries, elog doesn't handle deleting of a thread of more than 40 replies well - it crashes after deleting the 40th.  This leaves an orphan thread that causes other issues.  Do you have enough information to decided that this event always happens after x replies?

Hi Frank,

Good bit of detective work.  To me it suggests that something as yet undetermined occurs, that, when the 57th reply happens, causes the issue.  If that "something" hasn't happened, all is well.  Apart from Heinz varieties (not true, in fact), 57 isn't an obvious number; nor did it leap out at me at a quick look at the parameters in the coding.  My example of deleting more than 40 entries causing elog to crash was at least consistent, it happened every time.

I'm trying to think what this something might be.  With my (admittedly largeish) database of elog entries, starting elog from a cold start will take minutes of indexing before it will display home page or whatever.   Presumably it must count the number of entries in each thread (as otherwise why always 57?), yet if you stop and restart, it doesn't necessarily need to do the full indexing again - time between restarts I guess, the authors not considering the evil deeds I perform on yymmdda.log entries.

Bare me out on this, I once had software that ran a system, and every Thursday, without fail, it always did a full recalibration on every start up.  Since updates were issued on Fridays, I commented that it was just adding to our pressure, "as if it knew the day of the week"; it really was (and turned out to be) a day-of-the-week bug.  So, I've been right on more than one occasion.  Anything in common with the threads with cross indexing, such as day of the week, day of the month, time, especially if crossing midnight before the 57th reply? 

Another line would be to view the yymmdda.log files while you are making a normal reply.  In my v2.9.2 version, nothing is written until the Submit button is pressed, then either one or two files are modified or one modified and one new one created.  Is that still true with your version?  I ask because clearly one or two entry numbers have somehow already been "reserved" as if opened, but where?  That Autosave =0 looks to be a useful test to do.

Sorry I cannot be more help.  I'm not one of the development team, though I do have experience of (ab)using elog, and I'm a pretty rubbish coder as well.  but I do have some experience in bug finding!

David.