You cannot put the images into a subdirectory. The above link "pictures/ln2.jpg" will translate into a URL

http://<your server/pictures/ln2.jpg

and there the path pictures will be taken as a logbook name, and the server will complain that this logbook does not exist. Unfortunately you cannot see this error message since it happens during the loading of the picture, and the browser just displays a broken picture link. So put your image into the root of the elogd server and it will be fine.

I implemented this request in SVN revision #1974.

This is possible since the beginning: Click on Find, then check Display full entries and Printable output and hit Search. You get then a single page containing all entries from the logbook which you can easily print to get a hardcopy.

That sounds really strange. The only thing I can think of is that the demo entry conflicted with your other entries and two of them have the same entry ID. The entry ID is a unique key which identifies each entry. If you look into the raw logbook file 011108a.log with a text editor, you will see them as

$@Mid@$: 1
Date: Thu Nov 08 18:37:57 2001
Author: Stefan Ritt
Type: Routine
Category: General
Subject: Welcome
Attachment:
Encoding: ELCode
========================================
[B]Congratulations for installing ELOG sucessfully!
[/B]

This is a demo entry to ensure the elogd server is working correctly.
Click [I]"New"[/I] to add new pages and [I]"Delete"[/I] to delete this page.

so in this case the ID is 1. When you rsync'ed your entries into the demo logbook directory, you probably got two entries with the ID 1, which screws up elogd. Try to delete the file 011108a.log before you do the rsync. If you start elogd interactively with the "-v" flag, you will see some debugging output which can you help identify some problems:

[ritt@pc5082 ~/elog]$ ./elogd -v
elogd 2.7.0 built Dec 13 2007, 08:05:12 revision 1977
Config file  : /afs/psi.ch/user/r/ritt/elog/elogd.cfg
Resource dir : /afs/psi.ch/user/r/ritt/elog
Logbook dir  : /afs/psi.ch/user/r/ritt/elog/logbooks/
Indexing logbook "demo" in "logbooks/demo/" ...

Config [demo],                           MD5=F2E39262960C779517FEE576C17B1ED0

Entries:
  ID   1, 011108a.log, ofs     0, thead, MD5=81D89C3C94C6626BB7FF191026040E83
After sort:
  ID   1, 011108a.log, ofs     0
ok
Server listening on port 8080 ...

Stefan, I'm still stumped. I'm sorry for the hassle. 

I've removed all the demo entries from both my logbook and the demo. I restarted elog in verbose mode and everything seems normal. I've even run the binary from my old elog installation on the config and logbooks in the new place and it works like a champ.

So I think I've concluded that my new compilation is mucky'd up. The logbooks and config file are fine.

So for the record, the new installation is on MacOS 10.5 (Leopard). The compiler is gcc4.0. There is one warning when I compile:

I haven't yet been able to figure out what this last number is and if it should indeed be part of the date. Any ideas here?

Thanks,

-Val

First of all, you should also describe what has been improved. While for you it is important what is not working, for me it is also important what is working, to get more information if such a problem should occur again. So is your demo entry still there? Is the numbering still starting from 1 after you removed the demo entry?

The suspicious dates Sun, 09 Apr 2006 12:38:31 +52175311 ring actually a bell: Under MacOS, there was always the problem with the timezone. The last number in the date string is the time zone in minutes (where the hour has actually 100 minutes). So an GMT offset of one hour would be +0100, two hours +0200 and so on. Somehow it seems like your number are screwed up completely. So +52175311 is equivalent to ~59 years, which explains why your dates are around 1946. The question is now how did these number go into your entries? Have you copied the *.log files over from the old location or generated newly? Did the old files already have this problem (load the *.log files into an ASCII editor!). The time zone is handled inside ELOG in the following function:

/* workaround for wong timezone under MAX OSX */
long my_timezone()
{
#if defined(OS_MACOSX) || defined(__FreeBSD__)
   time_t tp;
   time(&tp);
   return -localtime(&tp)->tm_gmtoff;
#else
   return timezone;
#endif
}

As you can see, MAXOSX needs a different treatment. I got this code from someone else since I don't have a Mac available. One suspicion I have is that the variable OS_MACOSX is not defined correctly. There is some code which checks for __APPLE__ and then defines OS_MACOSX. Maybe put a print statement next to time(&tp); to see if that code is really executed.