Hi all,

I've encountered an occasional problem that seems to be exacerbated by having a message with many replies.

In our use of ELOG, we run lengthy environmental tests (often several days) in multiple temperature chambers (one logbook for each chamber).  We document the start of the test with a log entry, and then periodically create replies -- first to the original log entry, and then to each successive reply (no branching allowed), in order to document how far along the test is.

What I'm seeing is an occasional "hiccup" in the order of records -- in the snapshot below, you can see that the record ID(s) go (in chronological order) ....5654, 5655, 5656, 5659, 5657, 5658, 5660, 5661....

Additionally, in this example, record ID# 5659 and record ID# 5657 are duplicates -- duplicate time stamp and duplicate text.

Has anyone else encountered this? 

Thanks,
Frank
 

Hello!

We have a number of local ELOG servers, all mirrored to a single "remote" ELOG server.  We have users that create updates at the local server, and some at the remote server, which can run the risk of record conflicts.  Right now, the local servers perform a "Mirror cron" every 5 minutes, but even that leaves the door open to potential conflicts.

I found an open-source JAVA-based app called DirSync Pro (https://www.dirsyncpro.org/) which is capable of performing real-time mirroring, and has conflict handling.  I "took it for a spin", and it does do what it claims.  However, because each ELOG server performs record "indexing", it doesn't recognize records that aren't part of the current list of records. Restarting the ELOG server obviously corrects that, but I was wondering if there is another way to get the server to recognize newer "remotely-generated" records without restarting the server.

As always, I'm appreciative for the outstanding working that has been done to make ELOG the great application that it is!

 I'm looking for config examples of a shift log book where operators have to check a box or select their name from a list to prove they have read the latest entries in the log, can anyone help.

  Thanks for your time.

Ed..

I tried to reproduce the problem but could not. The config file uses "emtpy.html", "filtermenutext.html" and so on which I don't have. Same with eventlocation.

Rather than sending me all the files, can you strip down your elogd.cfg to a minimal version where you still see the problem. Then give me all information to reproduce it. You also have to tell me when the error occurs, like when you submit a new entry, scan through entries etc.

Stefan

Seems like I've discovered another bug here related to umlauts in my name. :D 

I was submitting this post and forgot to put an icon. Elog seems to have saved a copy of my message, which I could not edit since my username does not match the bugged name saved for this message.

> 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