We plan to use ELOG with mirror servers in a larger scale here, so I'm interested to know more about your problem.

Could you boil down your configuration to a minimum that still allows a reproduction of the problem and post those configurations as attachments?

Then I would try to reproduce it here. Best case I'll find a bug fix, worst case I'll reconsider the use of mirror servers ;-)

Sorry, that appears to be an undocumented bug fix :-)

The desired behaviour should be created by

Preset on reply subject = Re: $subject

The command "Subst" is supposed to overwrite the field after it is submitted.

From the documentation you will even find a nicer possibility:

Preset on first reply Subject = Re: $Subject

The prevent replies to build a long chain of "Re: Re: Re: ...."

Cheers Andreas

Attributes = subject, ... 
Options <name> = test{1}, ...  
Subst myvar = $shell(dir) 
{1} Preset subject = Test 
{1} Preset text = $myvar 

{1} Preset text = $shell(dir)

Hi Stefan,

I'm starting to get a similar problem to Lance's ("SQL Database").  Searching is beginning to take time.

In searching, I either can search one logbook (still relatively quick), or all of them.

I have my logbooks in groups, and often I know which group I want to search, and it would make the searching
much quicker were the search confined to just that group.  I don't think I've missed anything in the
documentation on this matter.  

If not a change to the elog program, is there another way of (say) arranging the logbooks that will achieve this?

We have been running elog for a few years now and its solid. The only thing is we are getting to 140k entries over a few books and its starting to slow down whist searching. My questions is can we go to an SQL type database rather than a flat file? Is it worth it? Is anyone running this type of configuration?

We have been experiencing corruption of logbook entries by elogd mirror synchronization. Has anyone else encountered this? Is there a known cause and/or workaround for it?

Details

We have two elog servers set up with identical elogd.cfg and password files, except that one server has "Mirror server" pointing to the other host. There are three logbooks defined.  (Their names are DoubleChooz, BigBrotherTable, and FlushingTable.)  When the mirror synchronization happens, whether by "Mirror cron" or by an administrator hitting the "Synchronize all logbooks" link, it often happens that entries requiring synchronization are corrupted on both servers (not just the one to which the entry was copied). This is particularly likely to happen if entries have been made on both servers since the previous sync.

Looking at the logbook files themselves, we see that the corrupted entries will have attributes from the wrong logbooks. E.g., we'll see an empty "Barometer: " line in a DoubleChooz logbook file, where "Barometer" is an attribute that is only in the FlushingTable logbook, or we will see there are unexpected DoubleChooz logbook attributes in the FlushingTable files.

Strangely, the entries will not be identical on the two machines after syncing, and they stay non-identical on further syncs.

Most disturbingly, data is lost from entries that were perfectly valid before the sync, on both servers.

This was happening with elogd 2.7.8, and continued to happen after upgrading to 2.8.0. Both servers are running Linux. One is a 32-bit machine and another 64-bit, in case that might matter (but read on).

I made copies of both servers' files and ran two elogd servers on my Mac on different ports, compiled from a fresh checkout of 2.8.0, and the same behavior was observed as I repeatedly made test entries and synchronized.  This suggests it isn't specific to Linux architecture, 64-bit or otherwise.

Attributes = subject, ... 
Options <name> = test{1}, ...  

Subst myvar = $shell(dir) 
{1} Preset subject = Test 
{1} Preset text = $myvar 

 I am getting the same message in the current version (V2.8.0-2312), if the "Preset text"  text body contains the equal sign '='. Then this message pops up and the HTML-editor dosn't show its menu bars, with the elog- or plain text editor this does not happen. It happens as well with firefox as with internet explorer.

best regards

Robert