Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 9 of 804  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
ID Date Icondown Author Author Email Category OS ELOG Version Subject
  685   Tue Sep 7 13:05:49 2004 Warning T. Ribbrockemgaron@gmx.netBug fixLinux2.5.4Re: text display of ascii files not a good idea
[...]
> Probably it is fine to display only files ending in '.txt' per default.
> In addition a file that has more than say 1000 lines should probably 
> also not be displayed (as default, optional OK).  

No, '.txt' would definitely not be enough for me. I'm using elog to log all
administration of our network. In many cases, I simply attach a configuration
file. All those files are plain ASCII and none of them end in '.txt' - and I
would most definitely like them to be displayed inline like they are now. In
fact, this change was the main reason for me to upgrade to 2.5.4

Maybe a configuration option or a "display attachment" button would be the
best solution, then?

Cheerio,

Thomas
  691   Wed Sep 8 13:46:56 2004 Warning Stefan Rittstefan.ritt@psi.chBug fixLinux2.5.4Re: text display of ascii files not a good idea
> [...]
> > Probably it is fine to display only files ending in '.txt' per default.
> > In addition a file that has more than say 1000 lines should probably 
> > also not be displayed (as default, optional OK).  
> 
> No, '.txt' would definitely not be enough for me. I'm using elog to log all
> administration of our network. In many cases, I simply attach a configuration
> file. All those files are plain ASCII and none of them end in '.txt' - and I
> would most definitely like them to be displayed inline like they are now. In
> fact, this change was the main reason for me to upgrade to 2.5.4
> 
> Maybe a configuration option or a "display attachment" button would be the
> best solution, then?
> 
> Cheerio,
> 
> Thomas

So to make everybody happy, it would probably be enough not to display inline any
*.ps file, is that right? Is there any other ASCII format, which should not be
displayed? PDF is binary, so it won't be displayed. What about long C files? Most
people want to see them. In the recent version there is the "Hide attachment"
link which can be clicked to not display an attachment inline. Mabe there should
be a "Hide default = 0|1" config option...
  698   Wed Sep 8 23:35:01 2004 Warning Heiko Scheith.scheit@mpi-hd.mpg.deBug fixLinux2.5.4Re: text display of ascii files not a good idea
> > [...]
> > > Probably it is fine to display only files ending in '.txt' per default.
> > > In addition a file that has more than say 1000 lines should probably 
> > > also not be displayed (as default, optional OK).  
> > 
> > No, '.txt' would definitely not be enough for me. I'm using elog to log all
> > administration of our network. In many cases, I simply attach a configuration
> > file. All those files are plain ASCII and none of them end in '.txt' - and I
> > would most definitely like them to be displayed inline like they are now. In
> > fact, this change was the main reason for me to upgrade to 2.5.4
> > 
> > Maybe a configuration option or a "display attachment" button would be the
> > best solution, then?
> > 
> > Cheerio,
> > 
> > Thomas
> 
> So to make everybody happy, it would probably be enough not to display inline any
> *.ps file, is that right? 

I think there should be size limit.  Imagine a multi MB text file (whatever it is;
elogd.c is already more than 1/2 MB and is likely to increase due to your
excellent support).  A client on an ISDN line would have to wait
several minutes and during this time elogd is busy and no other client can connect
(correct?).  Of course, if somebody really wants to see this file then there is
nothing to be done, but likely someone is flipping throught the messages using
to arrows on top to find the right entry....
So a configurable size limit seems appropriate, from which on 
only 'Display attachment' is displayed.  And/Or, for files
exceeding this limit, the first N (new config option) lines could be displayed.

But this should only influence ASCII files.  E.g. the behaviour for jpeg files
should not change, which is controlled by 'Hide default'.  Maybe a 'Display/Hide
defaut extension' option, where the extensions are listed that are to be displayed
is another idea, in addition to a 'Max Display ASCII inline size' option,
which can be set to zero to disable it altogether.

In any case, whatever you think is best.

Cheers, Heiko

> Is there any other ASCII format, which should not be
> displayed? PDF is binary, so it won't be displayed. What about long C files? Most
> people want to see them. In the recent version there is the "Hide attachment"
> link which can be clicked to not display an attachment inline. Mabe there should
> be a "Hide default = 0|1" config option...
  717   Sat Oct 9 14:25:23 2004 Warning Mike Stolovemstolove@rogers.comBug reportLinux2.5.4-5deleting the sole single entry in log causes crash with xrealloc
When creating new logbooks, I will create a single entry to test the  
configuration. After revising the configuration I want to delete that  
single entry and create a new one based on the revised config.  
  
elogd will crash every time upon deleting that single entry with an  
xrealloc error. Here are the syslog entries leading up to the crash:  
  
Oct  9 08:09:41 obstin8 elogd[20614]:  
GET /Support/1?cmd=Delete&nextmsg=0&confirm=Yes HTTP/1.1^M Connection:  
Keep-Alive^M User-Agent: Mozilla/5.0 (compatible; Konqueror/3.3; Linux)  
(KHTML, like Gecko)^M Referer: http://localhost:8080/Support/1?cmd=Delete^M  
Accept: text/html, image/jpeg, image/png, text/*, image/*, */*^M  
Accept-Encoding: x-gzip, x-deflate, gzip, deflate^M Accept-Charset:  
iso-8859-1, utf-8;q=0.5, *;q=0.5^M Accept-Language: en^M Host:  
localhost:8080^M Cookie: urem=0; upwd=dDRubjNyBDI=; unm=mstolove  
Oct  9 08:09:41 obstin8 elogd[20614]: xrealloc: not enough memory  
  
This is on a Slackware 10 box using kernel 2.6.7. Elogd is accessed  
directly, not through an Apache proxy.  
  773   Mon Nov 15 09:54:45 2004 Warning Marc Neigerm.neiger@synergie-inf.comInfoAll2.5.4-6Re: Announcement of RSS feeds
IE 6 chokes on the XML, below is what I get for 
http://midas.psi.ch/elogs/Forum/elog.rdf
(sorry this is in french).
So I assume all rss reader parsing the file with the MS XML parser shall also 
have a problem, this is the case with Avant Browser integrated RSS reader.

Cheer,
Marc

------------------------------------------------------

La page XML ne peut pas être affichée 
Impossible d'afficher l'entrée XML en utilisant la feuille de style XSL. 
Corrigez l'erreur, puis cliquez sur le bouton Actualiser ou réessayez 
ultérieurement. 


--------------------------------------------------------------------------------

Un caractère incorrect a été trouvé dans un contenu de texte. Erreur de 
traitement de la ressource http://midas.psi.ch/elog...

<title>Re: $message id  gives wrong value - Gernman traslalation of Back, posted 
by Ulrich Tr
  805   Wed Nov 24 00:17:45 2004 Warning Rich Persauddev2id at yahoo dot comBug reportAll2.5.4-6BUG: lost entry data
After THREE tries to enter a long detailed list of questions, all have been 
replaced by just one:  why do ELOG textareas and entry forms lose all data 
if the browser goes back/forward?  Or if a submission causes an error?  
Other forms in other applications don't have this kind of data loss.

Submitting this now before I lose it again.  Will submit rest of questions 
as separate entries.
  807   Wed Nov 24 00:44:09 2004 Warning Rich Persauddev2id at yahoo dot comBug fixLinux2.5.4-6Konqueror and Calendar widget
Date selection from the calendar widget does not work in Konqueror.  

Clicking on a date results in year being populated, but month and day are 
blank.
  815   Wed Nov 24 14:19:01 2004 Warning Stefan Rittstefan.ritt@psi.chBug fixLinux2.5.4-6Re: Konqueror and Calendar widget
> Date selection from the calendar widget does not work in Konqueror.  
> 
> Clicking on a date results in year being populated, but month and day are 
> blank.

I use following Javascript to populate the date:

function submit_day(day)
{
  opener.document.form1.d3.value = "24";
  opener.document.form1.m3.value = "11";
  opener.document.form1.y3.value = "2004";
  window.close();
}

which workes everywhere except in Konqueror. If you tell me how to convince
Konqueror to accept this, I'm happy to put it into the elog code.
ELOG V3.1.5-3fb85fa6