> Hi, Stefan.  When someone using a satellite connection tries to upload an attachment *or* edit a long entry, it fails and they are presented
> with an "Internal Server Error."  This is a huge improvement over the previous behavior of crashing elogd, but we were wondering if there is any
> hope of improving this further so that one can edit large entries or upload attachments over a slow (in this case, satellite) connection.  Do
> you have any ideas or plans on working on this further?  Apparently ELOG is the "only" service this user has trouble with from  home.

There was a timeout of 1 sec. in the elogd daemon, which probably is too short for a satellite connection. Unfortunately I have no satellite here 
around to test it, so I "blindly" increased it to 6 seconds in the current SVN version. Please give it a try. You can increase this yourself, its here 
in the code at (Rev. 2291) line 28270:

   FD_ZERO(&readfds);
   FD_SET(_sock, &readfds);
   timeout.tv_sec = 6;            <----
   timeout.tv_usec = 0;
   status = select(FD_SETSIZE, (void *) &readfds, NULL, NULL, (void *) &timeout);

so you can change the 6 to 10 or so. The disadvantage of a large value is the following: Suppose you submit an entry, and in the middle of the 
submission your browser dies (or the user closes it). If you have a timeout of n seconds, the elogd server will wait that time until it closes the 
connection. During this waiting time is cannot respond to other request, so it might look dead. That's why we should not make it too long.

- Stefan

The display mode is taken from the configuration option "Display mode = ..." only the very first time a users accesses a logbook. When the user switches to any other mode (summary, full) by clicking on the according menu option, the new mode is stored in a cookie in the browser and overrides the "Display mode = ..." setting. Maybe that is what you see.

Conditions won't work for IOption attributes. You need an additional attribute like:

First of all, why do you a reply to a very old message? For each new topic you should start a new thread.

I don't know exactly what goes wrong in your case. Just a few ideas:

• Having a '.' in a logbook name can cause trouble, better remove it
• Having a subdir starting with '\\' might work, but I never tried it, does it work if you use a subdirectory on the same drive just with "Subidr = \elog\..." ?
• There is also the option "Logbook dir = ..." which you might try

Indeed it was the JavaScript line

if (document.form1.Number.value != '- garder les valeurs d'origine -') {

which caused the trouble.  The "'" character closed the string '- garder les valeurs d', which caused an exception. I changed it to

if (document.form1.Number.value != "- garder les valeurs d'origine -") {

and now it should work fine.

What you need is

Restrict edit time = ...

as written in the manual.

> It is a good point, and surprised that this particular number of days was overlooked.
> 
> It only needs four lines added into elogd.c to achieve this.  Even with my notorious 
> c coding, I did it first time, but as I'm on linux, not a great help for you.  Indeed, 
> any other arbitary number of days could be added in, if you have the sources and means 
> to recompile.

David send me his modification and I put it into the main source code, so it will be contained in the next Windows 
version.

> I think windows versions are only updated on version number, not svn number, so it will 
> require a request to the great man himself(*) to produce a new version for windows.
>
> (*)Hint; Stefan likes the occasional beer.

Yepp ;-)

That should be possible with the following configuration options: