ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
1005
|
Wed Mar 23 12:54:51 2005 |
| Emiliano Gabrielli | AlberT@SuperAlberT.it | Bug report | Linux | r1592 | Re: wrong handling of attachment names | > 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 :-) |
1007
|
Wed Mar 23 20:35:55 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | r1592 | Re: wrong handling of attachment names | > 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. |
1010
|
Thu Mar 24 10:51:10 2005 |
| Emiliano Gabrielli | AlberT@SuperAlberT.it | Bug report | Linux | r1592 | Re: wrong handling of attachment names | > > 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 |
1017
|
Thu Mar 24 12:30:07 2005 |
| Emiliano Gabrielli | AlberT@SuperAlberT.it | Info | Linux | | Re: New Debian package (2.5.8+r1592) -- needs testing | > 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. |
1018
|
Thu Mar 24 13:21:28 2005 |
| Emiliano Gabrielli | AlberT@SuperAlberT.it | Bug report | All | 2.5.8 | Re: HTML 4.1 transitional validation fails | > as this url shows http://www.htmlhelp.com/tools/validator/problems.html#amp
> it should be used an HTML entity instead of the ampersand sign.
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 |
1072
|
Mon Apr 11 13:52:29 2005 |
| Heiko Scheit | h.scheit@mpi-hd.mpg.de | Bug fix | Linux | 2.5.7-1 | Segmentation fault when searching for empty regex | Segmentation fault when searching for empty regex
--------------------------------------------------
Searching for a regex like 'm*', which also includes zero 'm's, an empty
expression is found indefinitely in 'highlight_searchtext(...)', which
eventually results in an overflow of 'pt1'. The patch below fixes this
particular problem, but I would guess there are many other regular
expressions that would lead to an overflow of 'pt1', so its size
should definitely be checked before every 'strcpy(pt1,...)' and
the loop be aborted accordingly. (Or 'pt1' should be allocated
and enlarged dynamically.)
*** 14777,14782 ****
--- 14777,14784 ----
if (status != REG_NOMATCH) {
size = pmatch[0].rm_so;
+ if (size == 0) break; /* check for zero size -> infinite loop */
+
/* copy first part original text */
memcpy(pt1, pt, size);
pt1 += size;
***************
*** 14788,14795 ****
--- 14790,14799 ----
/* see also rsputs2(char* ) */
if (hidden)
+ /* need to check size of pt1 !!! */
strcpy(pt1,
"\001B\004style=\003color:black;background-color:#ffff66\003\002");
else
+ /* need to check size of pt1 !!! */
strcpy(pt1, "<B style=\"color:black;background-color:#ffff66\">");
pt1 += strlen(pt1);
***************
*** 14802,14814 ****
--- 14806,14821 ----
/* add coloring 2nd part */
if (hidden)
+ /* need to check size of pt1 !!! */
strcpy(pt1, "\001/B\002");
else
+ /* need to check size of pt1 !!! */
strcpy(pt1, "</B>");
pt1 += strlen(pt1);
}
} while (status != REG_NOMATCH);
+ /* need to check size of pt1 !!! */
strcpy(pt1, pt);
} |
1113
|
Mon May 2 12:29:11 2005 |
| Emiliano Gabrielli | AlberT@SuperAlberT.it | Bug report | Linux | 2.5.8-6 | rss feed title & conditional attributes |
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 ... |
1149
|
Tue May 17 21:38:36 2005 |
| Steve Jones | steve.jones@freescale.com | Bug report | All | 2.5.9 | Logbook locking issue | Stefan, any ideas on this problem?
Quote: | Our eLog is set to create logbook entry locks and after 30minutes prevent one from re-editing an entry, thus forcing a REPLY to be created.
SCENARIO: When an *attempt* is made to edit a logbook after the 30minute timer, one gets the message that EDITING is prevented and to use the browser "Back" button.
PROBLEM: The display now shows that particular entry to be locked, even though the attempt to edit was blocked. It appears that the lock flag is set prior to the "Edit" attempt being blocked and thus the lock flag is never "unset". |
|
|