I fixed this in revision #2204. The attachment names now stay the same. There is one tiny risk of screwing up, namely if you have the same attachment name in two different logbooks (accidentally also submitted at the same second and therefore the same time stamp). If you then copy these two entries to a third logbook, one attachment will overwrite the other one, but that risk is indeed really small. I actually had to re-write the link to the attachment inside the text body (even differently for ELCode and HTML encoding). So I'm not 100% sure I covered all cases, so just give it a try.

ELOG has been carefully designed not to contain memory leaks. The server for this forum for example runs for months without problem:

[ritt@midas ~]$ ps aux | grep elogd

elog      1958  0.4  3.1  39412 32940 ?        Ss   May09 178:16 /usr/local/sbin/elogd -D -c /usr/local/elog/elogd.cfg

So if you have a problem, it must be specific to your installation. You should note that if you up- or download big attachents, memory gets allocated for some network buffers to contain these attachments. The buffer is kept to contain the largest attachment, it will never shrink. But once established, it will also not grow. If you see however a constant increase in memory consumption, I would appreciate if you tell me how you do this. Like which configuration you use, if you just read entries or also upload them, etc. etc. Once I can reproduce exactly your problem, I can try to fix it. 

> 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 ;-)

Can you try revision #2206? 

> Here is the patch.  It works under both Solaris and Linux.

Thanks! I put that into revision #2207.

Are your sure about the firewall, because this is the usual reason for that problem. Can you "ping" your server machine from the other machine (like "ping <server>"), maybe you have some network problems.

> Hi Stefan,
> 
> I've been slowly moving threads, and twice now so far (and reproducably) had elog crash.
> 
> In each case, it is trying to move a thread with more than 24 entries; it copies the first 24 entries, then
> crashes with "Segmentation Fault".  It does not erase the lock file /var/run/elog.pid
> 
> I have got around this by manually copying the entries beyond no 24, then deleting the thread entry by entry.
> 
> I am aware that I have an old and limited machine (586, 256MB RAM, running Slack 10), and at first I was
> "content" to write it off as that; but when it crashed for the second time at exactly the same entry (the
> twenty-forth) even though the size of the entries would have been significantly different, I wondered if there
> was some factor within  elog that could affect this.
> 
> I've not tried it with Copy to:, but imagine it will also be affected as the only difference with this and Move
> to: is the deletion of the thread after all the entries had been copied.

This rings a bell: it's probably related to some internal stack overflow, since the entries are copied 
recursively. I have an idea on how to fix that, but I need time for that.