Stefan, the validation still fails on the ampersand ... here is an example of your online Demo elog: http://validator.w3.org/check?verbose=1&uri=http%3A//midas.psi.ch/elogs/Forum/920

> When an attached image name contains a space in its filename and attachment
> display is enabled elog builds a wrong url to the image:
> 
> http://arcolog.roma2.infn.it:8080/ARCO/050309_170709/peeling+002.jpg
> 
> instead of the correct one:
> 
> http://arcolog.roma2.infn.it:8080/ARCO/050309_170709_peeling+002.jpg
> 
> The more annoing thing is that elogs hangs on this. a strace shows a select
> on fd n°3 and 5 that loops forever (returning a timeout error):
> 
> send(4, "<141>Mar 23 11:36:25 elogd[22189"..., 35, 0) = 35
> rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 8) = 0
> select(1024, [3 5], NULL, NULL, {1, 0}) = 0 (Timeout)
> select(1024, [3 5], NULL, NULL, {1, 0}) = 0 (Timeout)
> 
> 
> May be the better solution is, after fixing the bug for backward
> compatibility with already uploaded images, to implement a forced characters
> substitution at upload time, replacing spaces and every character not in a
> "allowed chars" list with an underscore

donno if the following is correlated, otherwise there is another problem I
guess :-)
I attached a strace of elog, hope you'll find it useful.

- Irestarted the daemon
- attached strace to it
- requested the list for a testin logbook, few entries some quite big images 
  (two thumbnails, the other are old images get resized my the browser)
- repeted previous point a couple of times
- press F5 (mozilla-firefox)  the browser hangs 4ever
- stop the load
- repeat point 3, all right
- F5 => hangs
- F5 => hangs

there should be some problem, may be in the socket ?

> > - Irestarted the daemon
> > - attached strace to it
> > - requested the list for a testin logbook, few entries some quite big images 
> >   (two thumbnails, the other are old images get resized my the browser)
> > - repeted previous point a couple of times
> > - press F5 (mozilla-firefox)  the browser hangs 4ever
> > - stop the load
> > - repeat point 3, all right
> > - F5 => hangs
> > - F5 => hangs
> 
> I tried to reproduce this problem, but everything was fine. This problem was never
> reported by anyone else as well.

I tried to rise the problem with konqueror, and all works nice... running
mozilla-firefox gives the problem instead (also running the test at the same time), so
there should be something in firefox or in the interaction between firefox and elog.
I'll send you one of the elog giving the problems so you can test by yourself as you
asked.

btw:
http://midas.psi.ch/elogs/Forum/?mode=full&attach=1  does not gives any problem to me
even running firefox. so the problem may be in some my elog.cong parameter ...

> > - Irestarted the daemon
> > - attached strace to it
> > - requested the list for a testin logbook, few entries some quite big images 
> >   (two thumbnails, the other are old images get resized my the browser)
> > - repeted previous point a couple of times
> > - press F5 (mozilla-firefox)  the browser hangs 4ever
> > - stop the load
> > - repeat point 3, all right
> > - F5 => hangs
> > - F5 => hangs
> 
> I tried to reproduce this problem, but everything was fine. This problem was never
> reported by anyone else as well.

running ethereal I found a bug, hope this is the problem hanging my firefox (I think
we have a good chance it is :-P)

when I have thuimbs enabled, elog returns for the ".thumb" (or ".whatever".. thumb's
extension should be transparent to elog .. uhm... it can't be .. this is a problem)

anyway, having attached a pdf (a big one) and aving attachment display enabled (with
my thumbnails generated by my script)  elog returns for the displayed thumb a
Content-Type for application/x-pdf, instead of the correct image/jpeg. I think this is
the problem.

The only way for elog to know what is the correc\t content type for thumbnails is to
get it from a configuration parameter, becouse it is a chioce of the external script
used to generate them to choose the type of thumbs (jpeg, png, gif ... )
One conf parameter defaulting to jpeg may be the solution

When I create a new logbook (I used an existing one as a template) elog  
does not works anymore...  
  
- The problem is on elog user's file.. It seems elogd can't read it  
anymore:  
  
Cannot open file arco.users: Success  
Please use your browser's back button to go back  
  
- Here are some informations:  
sparcserv:/usr/share/elog# ps U elog  
  PID TTY      STAT   TIME COMMAND  
 5165 ?        Ss     0:08 /usr/sbin/elogd -f /var/run/elogd.pid  
-c /etc/elog.conf -d /var/lib/elog -s /usr/share/elog -p 8080 -n  
sparcserv:/usr/share/elog# id elog  
uid=106(elog) gid=106(elog) gruppi=106(elog)  
sparcserv:/usr/share/elog# ls -lha arco.us*  
-rw-------  1 elog elog 1,8K 2005-03-24 12:21 arco.users  
-rw-r--r--  1 elog elog  473 2005-03-23 10:41 arco.users_bak  
sparcserv:/usr/share/elog#                  
  
giving the arco.users file chmod a+wr does *not* make it work ...  
 
re-chmod-ing to -rw-------  AND restarting the daemon solves the problem 
and everything works nice ...  
 
any idea?  
  
 
 

When I define 2 attributes, by default and the second one has to be showed
depending on the first one value the elog correctly handle the thing, but
the rss feed shows an empty comma separeted field corresponding to the
conditional attribute not filled ...

Is it possible to have last runtime filtering and viewing method to be
stored in a cookie in order to make them permanent across navigation ?

I mean:
- if I decide to view "all" entries in the elog and then open one of them, 
  I'd like not to select "show all entries" again and again
- same thing if I choose to view last week
- same for every runtime filter and/or viewing option 

hope this is simple to implement :-)  thanks in advance 

is it possible to make the "+" sign, indicating a thread in the threaded
view, to be clickable in order to be able to expand a single thread each time ?

of course elog should remember the choice, so it will be possible to expand
N threads over the M total ones..

thanx :-)