Re: Moving entry (and replies) from one log book to another, posted by David Pilgram on Fri Jun 5 12:02:45 2009
|
Thanks Stefan, Downloading shortly and I'll let you know ;-)
> > Hi Stefan,
> >
> > When Moving entry (and replies) from one log book to another, is it possible to prevent elog from renumbering
> > the entries' ID number(s) ($@MID@$). While it may not be good practice, we've referred to these numbers in
> > cross-referencing, and it all goes wrong when an entry is moved from an "Open" thread to a "Closed" thread (cf
> > your FAQ about marking of whole threads).
> >
> > In the cases I'm thinking about, i.e. from main logbook to archive logbook(s), there would never be a clash of
> > ID number.
> >
> > Thanks,
> >
> > David Pilgram.
>
> I have implemented this feature in revision 2205. You need to set the new flag "Preserve IDs = 1" in the
> configuration. I have not tested this extensively, but I'm sure you will do it ;-) |
Auto-increment substitutions broken with records for multiple days, posted by Richard Stamper on Wed Jun 24 15:02:49 2009
|
With a logbook defined by
[test]
Theme = default
Comment = Test of auto-increment
Attributes = Batch
Subst Batch = %Y%m%d-##
the auto-incrementing of the Batch attribute within dates works when the logbook contains only entries for
today's date but otherwise will give a batch number of "01" for each entry.
Changing line 8714 of elogd.c as follows, from:
/* if date part changed, start over with index */
if (strlen(attrib[index]) > 0 && strncmp(attrib[index], retstr, loc) != 0)
old_index = 0;
else
/* retrieve old index */
if (atoi(attrib[index] + loc) > old_index)
old_index = atoi(attrib[index] + loc);
to
/* if date part changed, start over with index */
if (strlen(attrib[index]) > 0 && strncmp(attrib[index], retstr, loc) != 0)
break; /* <------------- */
else
/* retrieve old index */
if (atoi(attrib[index] + loc) > old_index)
old_index = atoi(attrib[index] + loc);
appears to fix this bug when I test it. This code is inside a loop stepping back through all log entries, and
the variable old_index is already set to zero before the loop. The existing code resets old_index whenever the
prefix of the attribute string (containing a date) does not match the "current" value of that prefix as found in
retstr (set using strftime). So, if there are any records for dates other than today then old_index is reset
and attribute values will be set with the counter = (old_index+1) = 1. The modified version stops comparisons
once a different date is seen, but assumes that records are date ordered. An alternative patch:
/* if date part matches */
if (strlen(attrib[index]) > 0 && strncmp(attrib[index], retstr, loc) == 0)
/* retrieve old index */
if (atoi(attrib[index] + loc) > old_index)
old_index = atoi(attrib[index] + loc);
does not make this assumption and also appears to work OK when I test it. |
Re: Auto-increment substitutions broken with records for multiple days, posted by Stefan Ritt on Thu Jun 25 10:09:18 2009
|
> An alternative patch:
>
> /* if date part matches */
> if (strlen(attrib[index]) > 0 && strncmp(attrib[index], retstr, loc) == 0)
> /* retrieve old index */
> if (atoi(attrib[index] + loc) > old_index)
> old_index = atoi(attrib[index] + loc);
>
> does not make this assumption and also appears to work OK when I test it.
Yes, this is the right one, it searches all entries to have the same date than the current one, and then looks for the
largest index which will be stored in old_index and later incremented by one. I committed your patch to the
repository. Thanks a lot. |
mail to localhost?, posted by Mike on Fri Apr 17 22:44:58 2009
|
Initially I thought you had to specify a port number after localhost for emailing.
As it turns out just putting "localhost" as the email server in the elog config
file works just fine. We have a strange problem where our elog server is running.
our outgoing mail has to be routed through port 465 and SSL. I had to set up
postfix and stunnel to handle this arrangement. |
Re: mail to localhost?, posted by Stefan Ritt on Fri Apr 24 12:25:16 2009
|
What was your problem (maybe others could benefit from this information...) ??? |
Long cookie content is not handled properly., posted by Simon Patton on Tue Apr 14 22:51:15 2009
|
I discovered the infinite loop in 2.7.5 which can happen when a cookie's content is longer that the cookie array
designed to hold it. I also note that this issue has been addressed in 2.7.6, but the solution does not appear
to be correct and it can end up completely confusing the cookie extraction.
In 2.7.5 the code was:
for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n' ; )
if (i < (int) sizeof(cookie)-1)
cookie[i++] = *p++;
While in 2.7.6 is became:
for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n';)
if (i < (int) sizeof(cookie) - 1)
cookie[i++] = *p++;
else
break;
This leaves 'p' pointing to the middle of the cookie's content and I can not see that this is corrected in the loop (sorry if I've missed that).
The solution I used to patch 2.7.5 was the following:
for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n' ; ++p)
if (i < (int) sizeof(cookie)-1)
cookie[i++] = *p;
which simply truncates the contents of the cookie (which is assumed not to be an elogd cookie) but leaves 'p' in the right place to extract the next one. |
Re: Long cookie content is not handled properly., posted by Stefan Ritt on Wed Apr 15 09:26:37 2009
|
Simon Patton wrote: | I discovered the infinite loop in 2.7.5 which can happen when a cookie's content is longer that the cookie array
designed to hold it. I also note that this issue has been addressed in 2.7.6, but the solution does not appear
to be correct and it can end up completely confusing the cookie extraction.
In 2.7.5 the code was:
for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n' ; )
if (i < (int) sizeof(cookie)-1)
cookie[i++] = *p++;
While in 2.7.6 is became:
for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n';)
if (i < (int) sizeof(cookie) - 1)
cookie[i++] = *p++;
else
break;
This leaves 'p' pointing to the middle of the cookie's content and I can not see that this is corrected in the loop (sorry if I've missed that).
The solution I used to patch 2.7.5 was the following:
for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n' ; ++p)
if (i < (int) sizeof(cookie)-1)
cookie[i++] = *p;
which simply truncates the contents of the cookie (which is assumed not to be an elogd cookie) but leaves 'p' in the right place to extract the next one. |
You're absolutely right about that. I incorporated your patch into revision #2192. |
Is there a way to import old log messages, posted by Joseph Le on Tue Apr 21 16:29:23 2009
|
I update my elog from version 2.7.5 to 2.7.6 and mistakenly replace configuration file. so i have to reconfigure everything from ground up. when my elog back online, old log messages are not show up. is there a way to import old log messages from old log book to new one.
thanks |