Hi David,

Which svn version of elog are you running - what does it say at the very bottom of the page (this forum says ELOG V2.9.0-2435); there *is* and issue about loading files and thumbnails with svn 2473, but it may also be in one or two prior to that (I found it with 2473, anyway).  Also, is elog running (taking CPU time) and not responding to anything after you try this (and you have to kill the daemon and restart), or crashing out at that point? I've had both behaviours at one time or another, for reasons I now understand, not related (I think) to this one, but the more evidence, the better chance that someone will find the problem.

David.

2455 is before the image handling issue came about, so it's nothing to do with those changes.

I see Andreas also finds that ImageMagick is apparently not invoked by elog to make a thumbnail of a .bmp file.  I tested it with a 5MB and a 0.5MB .bmp file this morning, so I don't really think it's the size of the file that is causing the problem - or that is my first guess, anyway.   But I suppose it is worth asking, what is the size of the .bmp file(s) you are trying to attach?  Just a thought, there is a parameter in the Global section of the elog.cfg - "Max Content Length".  I forget the default, I had to increase it when I wanted to attach a huge pdf file, wonder if that might be the issue (I had an error message come up with the pdf file, I wonder...)

The elog daemon can get stuck running like mad and not responding to anything.  One example I know is if you erase an elog entry (e.g. delete one file in the logbook directory, I'm not talking about using elog's own delete facility) the indexing of the entries is broken, and elog cannot handle that, it just gets stuck, consuming loads of CPU time doing I don't know what. 

I've got to go and do something in real life now, but I may get a chance to 'play' later, see if I hit any point that the experts can then work through

Hi Louis,

I'm a little surprised by your comment that you use symlinks 'to store your logbooks elsewhere'.

I start the daemon with

 /usr/local/sbin/elogd -p 8080 -c /home/logbooks/elogd.cfg -d /home/logbooks

so that both my logbooks *and* the config file are both based on my preferred location, which is a subdirectory of /home.  No symlinks  OK, themes are elsewhere, but for backup purposes, that's a rather lesser issue. 

I have no idea why the default logbook location is /usr/local/elog/logbooks which does not strike me as a sensible location (at least on Slackware).  Maybe such an odd location was to force users to choose a better location...(the -d switch).

To all:

I use Slackware (currently 13, I hear there are some issues with 14 for programs I wish use), and I compile from the sources.  Usually from random svn versions as a general pain-in-the-neck for Stefan.  I've never had to make a [Slackware] package for distribution - I have issued patches and/or source distribution, depending on your point of view.  If someone can provide the advice, I'd certainly try and do a Slackware distribution, but I do have Real Work to do as well, so it may not be done immediately.  I think Ubuntu is fairly close to Slackware, not sure about Debian, which I *thought* was close to Red Hat.

Now I *do* understand what some of the other contributors to this thread are doing, as I do something similar for other programs that are now unmaintained and no longer compile with GCC4 or earlier.  The email program I use is a ten-year-old binary & libraries I compiled under Slackware 7 (if not, 4), and I copy the relivent binaries, libraries and dependances across when I upgrade the o/s.  Yes, one day it will fall down.  Three other programs I regularly use are similarly now 'legacy'.  My 'C' coding isn't up to the major changes apparently needed to allow them to compile again with a modern compiler.
 

 Word of warning about fake email addresses - if your system suddenly does start to send out messages to them, you'll start getting otherwise mysterious email messages back about being unable to deliver and other such comments.  I speak from experience - although in my case the puzzle was finding what was generating the messages in the first place (not elog, another program as it happened).

I suggest you also include

Suppress default = 3

in your configuration file, which also stops them being generated in the first place. 

Although I was unaware (or had totally forgotten) that there was a 'Suppress email button' as mentioned in the documentation.

I use plain encoding, cannot answer for the others but it should do the trick as it's in the documentation.  I'm using Firefox some large number and 2.9.2.-2475

I do what I believe you want, and get it by having the following line in my config file for that logbook (which is part of elog.cfg):

 Prepend on reply = \n

This gives a blank line at the "top" of the entries when you start a reply, and all the previous entries gain another "> " unless you've also altered that default behaviou (as in fact I have).  The result then looks like:

Latest line of text

> Previous entry

> > Previous entry to that

 I use elog's built-in ticketing system, and use the auto-generated ticket number to cross-reference with other matters/documents/files.  Much of the documentation for tickets is rather buried away under Subst <attribute> = <string>.

I've not found a way to link from an entry to a set of entries in another thread by their ticket number, particularly across more than one logbook.  [This is possible via their elog entry number, and which logbook it is in].  The former would be usefil to cross-reference an incident which you identify external to the elog system - "Oh, it's another one like [Ticket no] NOV12-001" possibily easier than "Oh it's another one like elog:archive12/67142 ".  Oh, the last bit should be highlighed as a (non-existant) link here, to show my point, nice of the ticket could be as well.

On the plus side, you can arrange the ticket number to show up in the thread display, quick search by ticket number, run different ticket colours (as it were) in different logbooks (i.e. different prefixes).  Just ensure you don't archive the latest entry, as that can lead to duplication of ticket numbers.

Message ID is the internal numbering of each entry.  It is the number that is used internally for generating the threads, and which you can reference with the elog:[message ID] code within an entry to cross reference the entry with that message ID.

"Ticket" is the name of an attribute.  You define the attribute "Ticket", and can preload the attribute with the format  you require(*).  In the following extract of an elog.cfg file are the relivent lines to generate tickets, show the ticket number in the thread display, search for a particular ticket, and allow it to be edited when writing an entry - there are reasons.  The attribute "Organisation" here is an example of another attribute you would enter with the initial entry, of course there will be others specific to your requirements.

Attributes = Ticket, Organisation, ...

Preset ticket = T#####

Thread display = $Ticket: $Organisation, ...

Quick filter = Ticket, ID

When you start an new entry, the Ticket attribute is prepopulated with a number.  The first time will be T00001, subsequently it will be one higher than the currently existing highest ticket number in the logbook.

Why might you edit the ticket number?  You may wish to go back and edit an old (complete) entry's ticket number so it has some obvious name - perhaps the solution of what proves to be a stock problem, that has become known by a pet phrase, so it can be found by searching for that phrase in the quick fillter "Ticket".  That is a more advanced use of the ticket system.

 (*) Further on the format of the ticket is in the documentation under Subst <attribute> = <string>

Sorry for multiple edits, why cannot I cross-reference an entry in this forum as I can in my local logbook?

 Hi Barend,

The counting of entries, or even "tickets", only works within a particular logbook.  If you archive a set of entries to another [archive] logbook, the archived set disappears from view of the original logbook.  Should that entry, from logbook to archive, be the *latest* thread, then there is the danger of over-writing message ID, Ticket No and the like.

My policy to prevent the problem is to archive only threads that are say (depending upon use) a month after last entry..