ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
66380
|
Fri Jun 5 12:02:45 2009 |
| David Pilgram | David.Pilgram@epost.org.uk | Question | Linux | 2.7.6-2191 | Re: Moving entry (and replies) from one log book to another |
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 ;-) |
66411
|
Wed Jun 24 15:02:49 2009 |
| Richard Stamper | r.stamper@rl.ac.uk | Bug fix | All | 2.7.6-2191 | Auto-increment substitutions broken with records for multiple days |
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. |
66414
|
Thu Jun 25 10:09:18 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug fix | All | 2.7.6-2191 | Re: Auto-increment substitutions broken with records for multiple days |
> 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. |
66322
|
Fri Apr 17 22:44:58 2009 |
| Mike | mike@raghuexim.com | Question | Linux | 2.7.6-219 | mail to localhost? |
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. |
66329
|
Fri Apr 24 12:25:16 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.7.6-219 | Re: mail to localhost? |
What was your problem (maybe others could benefit from this information...) ??? |
66314
|
Tue Apr 14 22:51:15 2009 |
| Simon Patton | sjpatton@lbl.gov | Bug fix | All | 2.7.6 | Long cookie content is not handled properly. |
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. |
66315
|
Wed Apr 15 09:26:37 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug fix | All | 2.7.6 | Re: Long cookie content is not handled properly. |
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. |
66325
|
Tue Apr 21 16:29:23 2009 |
| Joseph Le | josephle9@gmail.com | Question | Windows | 2.7.6 | Is there a way to import old log messages |
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 |