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

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

> > Using 2.5.8, if I set "Protect Selection page" to 1, then elogd seg faults
> > as soon as it is accessed.
> 
> Thanks for reporting this bug. I fixed it and committed the change to CVS.
> 
> - Stefan

wow, who's Speedy Gonzales ?!? :-P

> > Using 2.5.8, if I set "Protect Selection page" to 1, then elogd seg faults
> > as soon as it is accessed.
> 
> Thanks for reporting this bug. I fixed it and committed the change to CVS.
> 
> - Stefan

wow, who's Speedy Gonzales ?!? :-P

> > It seems to work nice to me.
> > Just another suggestion: I think it would be better to insert a commented out
> > example for all allowed parameters in the distributed  /etc/default/elog
> 
> Thanks for the test.  Please note that, /etc/default/elog is partially auto
> created during the installation.  All options except PIDFILE and CONFFILE are
> currently listed (as configured or commented out).  If you didn't see these
> options (after the update), there must be a problem.   Did you mean the lack of
> PIDFILE and CONFFILE in the default file?

no, my bad (it seems :-P) .. I re-installed the package now on my laptop and seems
to work fine... maybe I have swapped the diff result when installed yesterday.

Making tests I found another problem, her is the report:

####
root@emc2:/home/albert# apt-get remove elog
Lettura della lista dei pacchetti in corso... Fatto
Generazione dell'albero delle dipendenze in corso... Fatto
I seguenti pacchetti saranno RIMOSSI:
  elog
0 aggiornati, 0 installati, 1 da rimuovere e 0 non aggiornati.
È necessario prendere 0B di archivi.
Dopo l'estrazione, verranno liberati 2444kB di spazio su disco.
Continuare? [S/n]
(Lettura del database ... 152033 file e directory attualmente installati.)
Rimuovo elog ...
Stopping ELOG daemon: elogd.
root@emc2:/home/albert# rm /etc/default/elog
rm: rimuovere regular file `/etc/default/elog'? y
root@emc2:/home/albert# apt-get install elog
Lettura della lista dei pacchetti in corso... Fatto
Generazione dell'albero delle dipendenze in corso... Fatto
I seguenti pacchetti NUOVI (NEW) saranno installati:
  elog
0 aggiornati, 1 installati, 0 da rimuovere e 0 non aggiornati.
È necessario prendere 0B/530kB di archivi.
Dopo l'estrazione, verranno occupati 2444kB di spazio su disco.
Selezionato il pacchetto elog, che non lo era.
(Lettura del database ... 151926 file e directory attualmente installati.)
Spacchetto elog (da .../elog_2.5.8+r1592-1_i386.deb) ...
Configuro elog (2.5.8+r1592-1) ...
cat: /etc/default/elog: No such file or directory
Starting ELOG daemon: elogd.
####


So, removing an existing elog (not purging) and installing again raise the error.
Why installation creates the default/elog file only the first time ?  I think it
shoud do the job everytime (and everytime ask the user is there is a diff to be
checked)

> Hi to all,
> 
> I've prepared a new Debian package.  This version will probably be the one
> which you'll find in Sarge/stable.
> 
> There are some invasive changes in this version which call for a serious
> test.  In accordance with a suggestion, I've changed the configuration
> mechanism.  For details, please read the NEWS.Debian file attached.
> 
> Could the Debian users who follow this forum test it and give some feedback?
> You can download the package from the following link:
> 
>   http://l10n-turkish.alioth.debian.org/debian/elog_2.5.8+r1592-1_i386.deb
> 
> Thanks in advance for your participation,

btw, what about in including in default/elog also a voice for the "-x" switch ??

It is a security related thing and may be passed only on the command line to the
daemon, so it should be governed by the system elog admin.

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 ?