If you download the standard package, it installs a demo logbook on your computer which you can use as a personal logbook. It uses port 8080 by default, although this can be changed. Then only thing you need to do is to make sure that port 8080 is blocked on your firewall. Read your OS documentation on how to set-up and use a firewall. Once you block port 8080, the data cannot be accessed from outside your laptop. 

 Thanks Stefan,

I've properly set the firewall, and access is forbidden from outside. But when I don't have internet access, how could I open my database?

Furthermore: how it is possible to change the "demo" title ? and what's the procedure to open other databases?

Thanks again for helping

Sara

You can start the elogd daemon even when you don't have internet access, and access your database locally under http://localhost:8080. For changing the title of a logbook, please read the documentation. 

Ok, i compiled the code below and ran it,
it prints out:

timezone: 134513644

but in BASH shell if i type DATE, then this is the output:
Mon Oct 18 09:44:00 NZDT 2004
so it does know about NZ time...

Anyone got ideas?

Thanks all.
G.


> > Date:  Mon, 11 Oct 2004 12:26:28 -3736512
> 
> The timezone offset (-3736512) is obtained from the "timezone" variable, which
> is initialized with the tzset() function inside elogd. See "man tzset" for
> details. It looks like if the timezone on your FreeBSD box is not correctly
> defined. 
> 
> Try to compile and execute following C program:
> 
> #include <stdio.h>
> #include <time.h>
> 
> main()
> {
>    tzset();
>    printf("timezone: %d\n", timezone);
> }
> 
> This should print something like "timezone: -3600". If not, you might consider
> defining the "TZ" environment variable. Maybe some FreeBSD expert knows some
> details about this.

 1. It appears that some times find_thread_head is called with message references that do not exist. That is not good.

I put in a little check like this  before seeing if the message has an "in_reply_to" reference:

The line:

if (lbs->el_index[i].in_reply_to)

becomes:

if (i < *lbs->n_el_index && lbs->el_index[i].in_reply_to)
 

2. The trouble started when I deleted a message in the middle of a thread, which left the thread badly "connected" (references to a deleted message).

3. Also, when a thread is badly connected, it is a problem moving messages to a different logbook. ELOG complains that it cannot access the message (with the invalid reference). But ELOG should ignore it, since the message was deleted.

Soren

 It would be nice to have this corrected. The problem occurs when you select (read) a message which refers to another message via "In-reply-to", and this message does not exist.

Soren

Soren, you're not alone!  I've had similar problems, as did Sara Vanini (elog:67077).

In my case, it is because the "move" or "copy" function does not move all the messages in very long threads.   To be more precise, elog will crash in the attempt to move a long thread - say over 40 replies, I don't know for sure.  Sometimes it has already moved the entire thread before it crashes, sometimes not.  I'd not flagged it up as an issue because I could not be sure it was not a memory issue with the old (>12 years) linux box I was using earlier this year, but it still happens on this new (to me, only 3 years old) linux box.

Whether it is the number of entries, the total memory size of the thread or some combination, I don't know.

I've found that in the "move" case, it has not deleted all the messages from the donor thread, so that there is a semi-thread still hidden there.  Should one by chance select that semi-thread, (because it is found during a search) elog goes into infinate loop, which requires a reboot of this linux box to fix.   Certainly the pinning down the issue to the missing entry referenced by an <i>In reply to:</i> explains this part of the issue.  Of course, deletion of one entry within a thread, or other adjustments will do the same thing, just as you (Soren) point out above.

If it happens to me, I will go in to the yymmdda.log files and fix the problem, be it deleting the entries of the semi-thread, moving across missing entries from the donor to the acceptor logbooks, adjusting the <i>Reply:</i> and <i>In reply to:</i> lines, but that is quite a time consuming and error prone exercise.

Forget the previous post:
I cannot reproduce the problem with the latest version of elogd (2.9.2-2475).