Display Subject               = <b>$subject</b>

if (p && strchr(str, '>') && p >= str && *(p-1) != '\\')

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

> 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

A correction:
the url generated is correct, infact modifing by hand the names of the files and
the "Attachment:" entry in the .log all works fine

the same problem happens if the filename is, for example foo.JPG and not foo.jpg :
http://arcolog.roma2.infn.it:8080/ARCO/050221_171508/Graph3.JPG
loops forever

http://arcolog.roma2.infn.it:8080/ARCO/050221_171508/Graph3.jpg
works correctly


so, elog does not like spaces in filename and/or uppercase extensions. the
solution is, IMHO, to sanify the uploaded filename at uploading time :-)

> 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

This is on purpose. If you want to save an attachment locally and right click on
the attachment, and select "Save link as..." in your browser, then the default
file name is taken from the link. If your original file namw was "peeling
002.jpg", then you want again the same name, and not "050309_170709_peeling
002.jpg, because you would have to delete the date/time part of the file name
each time which would be annoying. That's why I have chosen to put an artificial
"/" between the date/time and the original file name. On the elog side, it's
converted correctly back to the file name.

The problem with blanks in attachment names I could not reproduce. See this
post, which contains an attachment with a blank in it. As you can see, this does
not crash the server. 

> > 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
> 
> This is on purpose. If you want to save an attachment locally and right click on
> the attachment, and select "Save link as..." in your browser, then the default
> file name is taken from the link. If your original file namw was "peeling
> 002.jpg", then you want again the same name, and not "050309_170709_peeling
> 002.jpg, because you would have to delete the date/time part of the file name
> each time which would be annoying. That's why I have chosen to put an artificial
> "/" between the date/time and the original file name. On the elog side, it's
> converted correctly back to the file name.
> 

yes I notice this after posting :-) sorry

> The problem with blanks in attachment names I could not reproduce. See this
> post, which contains an attachment with a blank in it. As you can see, this does
> not crash the server. 

Ok I can confirm this.
The problem arises, for me, when upgrading to the new version of elog having yes
some old entries with attached filenames containing spaces and/or uppercase extensions.

It seems that uploading files with spaces in the name *now* works well... so the
problem should be somewhere in the handling of existing attachments, not rised when
the attachment is uploaded with the current version of elog ... it's quite strange

> 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 ?