'Reply' removes attachments from the original message, posted by Alexander ZVYAGIN on Tue Apr 22 17:13:08 2003
|
It seems when I use "reply" with an attachments, the original attachments of
the message are removed.
I use elog-2.3.5
Alexander. |
|
segmentation fault, posted by Heiko Scheit on Fri Feb 13 12:18:19 2004
|
Around line 2240 (in loc()) in elogd.c the following is written,
which results in an infinite loop, since loc() recursively with
the same argument "Change %s".
/* special case: "Change %s" */
if (strstr(orig, "Change ")) {
sprintf(result, loc("Change %s"), orig + 7);
return result;
}
For now I just commented these lines. |
|
elog (not elogd) submit does not work anymore, posted by Heiko Scheit on Fri Feb 13 12:21:25 2004
|
Somehow elog does not use the -s option (subdir) anymore,
resulting in a 'HTTP/1.1 404 Not Found' error.
For now I am using elog from version 2.3.9 together with elogd v2.5.0,
which seems to work OK. |
|
elogd does not exit on SIGTERM, posted by Heiko Scheit on Wed Feb 18 16:54:27 2004
|
When trying to stop elogd processes with the kill command
elogd exits only after access to the logbook.
It should exit immediately, maybe after some cleanup. |
|
Re: elogd does not exit on SIGTERM, posted by Stefan Ritt on Thu Feb 19 09:38:13 2004
|
Noee. Here it works immediately.
Can you try with a fresh server from the distribution, with the example
elogd.cfg, to see if there is any difference?
The killing is handled in the funciton ctrlc_handler(), which sets _abort =
TRUE. This is checked in line 16195, just after the select(), and the main
loop is exited. The select finishes after one second, although I believe
that the kill signal also terminates the select prematurely. The kill
command and a Ctrl-C keystroke should work the same way, they both generate
a SIGTERM or SIGINT signal. |
System Error / Hangs with ELPG and threaded Msg's under Win 2k3 Server, posted by Ulrich Trüssel on Sat Feb 28 16:46:41 2004 
|
Since I'n not a programmer I's like to be very carefulls with bug
reports, but after testing for a while, I belive this my be a bug or
something else:
I have 2 systems running ELOG 2.5.1:
1. uSE Linux 8.2, KDE 3.2 = NO problems at all! ELOG work's in every
function quiet well!
2. The Internet Server (of my friend): Windows 2003 Server, All MS paches
installed, Running IIS 6.0 Port 80) and ELOG 2.5.1 (Port 8080) under
FireDeamon 1.6GA (actual release) as a Service (Deamon).
Problem under Win 2k3:
This works very well, even with several users on the system and on ELOG
as long as there is not msg. threaded! Is a Msg. Treaded ELOG produces
the msg. showen in the attached Jepg-file below on Win 2k3.
The problem occurs as soon as Elog would change to the threaded display
or by clicking "Repaly" in the menu. Rights etc. are aleady checked on
the file system and are looking well. Everithing will work well as
nothing is thraded or testing locally under Linunx.
Does anybody
have an idea??? It my by a bog on Elog as well as from Microsoft or a
problem produced by a dummy user (me...!). Since Linux don't have the
problem and the same cfg-file and log-files are working well if I don't
use mode=threaded as well as Display mode = threaded I believe it my be a
realchance not to be the personal factor of the dummy user...
ThankX for every hint!
|
|
Using select menu option to move multiple logbook entries to another logbook, posted by Robin Peterson on Fri Jun 4 22:40:44 2004
|
I'm trying to configure this thing to be able to filter on a set of
criteria, choose select, choose toggle all, and then choose "Move to
Complete Work Requests".
I've been able to select a specific logbook entry and move it, and I've
been able to filter and select and toggle, but I can't figure out how to
get the Move To option to show up on the main logbook menu....
what am I missing?
robin |
|
Re: speeding up elog : gcc compile optimizations, posted by Drew on Tue Aug 3 16:59:36 2004
|
> > Is there something else which is making this difficult to do?
>
> Not really, but hsearch() & Co. are not available under Windows, so I have to extract the
> source code from the GNU C libarary or so. Since the last discussion I had lots of other
> topics on my to-do list, such as mirroring and cloning, but the speed issue is getting more
> and more up on the priority list.
Speaking of windows I'd like to note that when I moved my call tracking config from a slow BSD
system (PPro 200Mhz) to a faster windows system (P3 733M) I noted a huge slow down in the
interface. Talking about perhaps 1-2 seconds before to 10-15 seconds after. Using
sysinternals file monitor I see that elogd is hammering each log file in the directory. Not
sure what else is going on. 309 log files - only 1.25Meg.
Anything I can do short of pruning down the files?
[Edit: In both cases above my default view is filtered and sorted - so that I only see things
with a specific status. Taking away the filtering resolves this hit - but does not explain the
speed difference between platforms.]
-D |