Hello,

We used the Elog RPM binary installation method to install Elog. Our security scanners are complaining that Elog discloses the version information when you hit a missing page (404 error).  How can I hide this version info? Is there a snippet of code somewhere that I can comment out?

Any help is appreciated.

-Rich

Hello,

We used the Elog RPM binary installation method to install Elog. Our security scanners are complaining that Elog discloses the version information when you hit a missing page (404 error).  How can I hide this version info? Is there a snippet of code somewhere that I can comment out?

Any help is appreciated.

-Rich

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 David,

Thanks for the quick response!  Well, I'd have to say that the sequence is as tangled as it looks in the logbook -- I've attached a copy of the log file for your reading pleasure. 

This one is definitely a "head-scratcher" for me...it definitely seems like it is more prevalent on log entries with many replies.

Thanks,
Frank

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 all,

I've encountered an occasional problem that seems to be exacerbated by having a message with many replies.

In our use of ELOG, we run lengthy environmental tests (often several days) in multiple temperature chambers (one logbook for each chamber).  We document the start of the test with a log entry, and then periodically create replies -- first to the original log entry, and then to each successive reply (no branching allowed), in order to document how far along the test is.

What I'm seeing is an occasional "hiccup" in the order of records -- in the snapshot below, you can see that the record ID(s) go (in chronological order) ....5654, 5655, 5656, 5659, 5657, 5658, 5660, 5661....

Additionally, in this example, record ID# 5659 and record ID# 5657 are duplicates -- duplicate time stamp and duplicate text.

Has anyone else encountered this? 

Thanks,
Frank
 

Hi Stefan,

I pulled the code from the repository but was not able to build it.

Sorry, I'm not a developer. Is there a good documentation you can recommend on how to do this for a Windows installation incl. how to setup a build environment?

No chance to get a more recent Windows version already precompiled? ^^

Regards,

daniel

> I found two potential memory leaks which I fixed in the git version, so you can try again.

Just tested, and it works! Many thanks for very quick patch!

> 
> Another possibility, which is actually preferred, is to limit the size of the subject filed to a reasonable number. You can do that with following 
option
> 
> Format subject = 0, attribname, attribvalue, 80, 200

Yes, that is a good suggestion, I'll implemented it.

Many thanks again!

Best,
  Stefano

> 
> This shows the subject line with a width of 80 characters, but does only allow 200 characters to be entered there.
> 
> Best,
> Stefan