I upgraded my system, including the version of Firefox.

I normally view the topic in Threaded Collapsed mode, right click on the entry I want to reply to, to open a new
Tab.  However, I made a mistake an opened a new Window, as the two 'open' modes in Firefox swapped around.
But no worry, I thought, made my reply as usual.

However, when refreshing the topic afterwards, seemingly randomly distributed throughout the topic were
additional lines, with the latest entry showing up emboldened (but not as a clickable link), and the only
difference being the ID number which showed as 0 (zero).

Deleting the reply only caused the previous reply to show up randomly etc.

In effect, the latest entry is (randomly?) scattered throughout the topic - even in between entries older than
any in that thread, so it's not individial entries in that thread showing up.

The only way to get rid of it was to erase the whole directory, and re-install from backup (which, as it was the
first entry since the new installation, wasn't painful).  It's been fine since - but only so long as I open a
thread in a new tab, and not in a new Window.

I guess the real question is just what is added to some file - perhaps the .cfg file? - that using a separate
window causes this behavioir?  Any whay only as a new window, and given how elog is supposed to work on many
computers, why on this stand-alone computer running two sets of the same browser?

It happened once before at the end of last year during a regression backwards owing to the newer computer
failing and turning back to an older one with older OS and older firefox, where I did the same thing (in
reverse).  As I didn't investigate at that time, I still have the mystery line showing up in that topic.

Sorry this is a bit rambling, but its very hard to describe!

> > I upgraded my system, including the version of Firefox.
> > [...]
> > Sorry this is a bit rambling, but its very hard to describe!
> 
> A picture can say more than thousand words.
> Can you reproduce this with a simple configuration?
> If yes, can you attach the configuration, the *a.log files,
> a description of what firefox version you're using and please:
> some screenshots of "before" and "after"?
> 
> Thanks!
> Andreas
That's odd, I cannot reproduce the problem today - except on the topic [logbook] it already exists on.
Yet nothing has changed.  
I've looked for hidden files, hidden control codes in the *a.log files...  this one had better be put on the
back burner until I can find a way to reproduce it (!).

Philippe Rousselot wrote:

Philippe Rousselot wrote: Andreas Luedeke wrote: Philippe Rousselot wrote: Bonjour, tout est dans le titre. Merci For those who speak strange languages, I asked how to get a french version of elog. By the way, this is my second mail because I forgot to give an icon to the first mail, and when I hit Back to do so, my text was erased. Bug or normal obnoxious attitude of my browser ? Thanks in advance Philippe  ELOG comes "internationalised": you just need to set your desired language in the configuration files. Language = french in the configuration file elogd.cfg does the trick. If you are capable to read the English language (which I suppose ), then I would recommend reading the manual, e.g. https://midas.psi.ch/elog/config.html#global Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Detect language Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish ⇄ Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Detect language » English   PS: I happened to have the same problem (text erased after "back") when I had javascript disabled in the browser. If you have it enabled, you'll get a popup window that tells you what mandatory fields are missing in your post. Then you'll not need to use the back button.  Hi, Thanks for the answer. I tried this (directly from de setting menu in the demo account as well as from the onfig file) : I modified of course the text that could be modified directly from there such as menus and submenus. I added Language = french, I restarted the server, clear the cache of firefox (IE as well), but list, new and so on appear in english even they are in the locale file... Indeed, the manual is very interesting concerning javascript, it is activated ... Thanks again Philippe  Found it !   I wanted to have locale set in the folder demo (so I could have one in french and one in english). Once language set in globals everything went fine. Almost... Philippe

 May I make a suggestion here?  Something I do for other reasons.  I run two separate elog daemons, each with their own configuration files.  In this case you could have one configuration file tout en française, and the other in English.  This gets around the language setting being in the Global section of the configuration file elog.cfg

Of course this needs a little planning, for example a small script/batch file to start up each daemon with the correct config file. - so on my linux system, I start one with

/usr/local/sbin/elogd -p 8080 -c /home/logbooks/elogd0.cfg -d /home/logbooks

and the other with

/usr/local/sbin/elogd -p 8081 -c /home/logbooks/elogd1.cfg -d /home/logbooks

 

The disadvantage is that you cannot click between French and English by the tabs along the top of the elog page, you'd have to switch between browser windows.

Hope this helps.

David.

Andreas Luedeke wrote:

David Pilgram wrote: [...] [...]  May I make a suggestion here?  Something I do for other reasons.  I run two separate elog daemons, each with their own configuration files.  In this case you could have one configuration file tout en française, and the other in English.  This gets around the language setting being in the Global section of the configuration file elog.cfg Of course this needs a little planning, for example a small script/batch file to start up each daemon with the correct config file. - so on my linux system, I start one with /usr/local/sbin/elogd -p 8080 -c /home/logbooks/elogd0.cfg -d /home/logbooks and the other with /usr/local/sbin/elogd -p 8081 -c /home/logbooks/elogd1.cfg -d /home/logbooks The disadvantage is that you cannot click between French and English by the tabs along the top of the elog page, you'd have to switch between browser windows. Hope this helps. David. Does this work nice and stable for you? I've tried at the beginning to run two server on one host, one in German and the other in English. I experienced occasional server crashes (every few days) and assumed that they were related to two mirrors running on the same host. A mirror server just for a second language was not of big importance to me, therefore I did shut down the mirror server. And the server stopped crashing then. Was that just coincidence? I recognised that you are not running a mirror, you let both logbook processes access the same data. Is that save? Did you ever see data corruption from two processes modifying the same data? Or is one of the ELOG servers not used much?   Thanks for sharing your experience! Andreas   Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Detect language Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish ⇄ Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Detect language » English

 I'd better put some caveats in here, then!

The two daemons on my host were never accessing the same subdirectories of /home/logbooks (this is my location, for ease of data backups (*)), and they were running with owner 'nobody', i.e. that's the owner of each directory.  In that sense they were independant, and as I was the only user, only one daemon would be working on files at any one moment. 

Next is that my system is never running for so many days uninterrupted.  The computer sometimes has to be booted into Windoze to use the CAD program, or even was just shut down and switched off.

I realise now that my earlier reply may have lead people to think they could work on the same data with two separate daemons (so as to work in their own language, but the data would be in both....) but I never meant to give that impresssion.  I've simply not tried it.  It might work on a stand-alone system, but I don't know how elog copes with multiple users accessing data at the same time - lock files?  check to see if data has been altered before allowing a submission is probably not done (it would make a branch if branches were allowed, I think) - I don't have the experience of using elog under these circumstances.  I thought Philippe Rousselot wanted a French language logbook and a separate English language one.  If I'm wrong there, sorry to raise his hopes.

Make a nice little project for someone to explore the limits, and maybe find what changes are needed.  Not necessarily to impliment it, though.

As for data corruption, never seen any, but I suppose the general warning of keep the backups well up-to-date.  I have had trouble with data, in particular moving data between logbooks, and this is one reason I have experience of how to make an elog entry using a text editor, as well as how to modify entries - to assemble scattered entries into a thread, or split a long thread into two shorter ones for ease of handling.  But I don't think those were ever connected to having two deamons running on one host, it happens when just one is running.

(*) In principle, all my data can be put on a memory stick - currently 16GB - and then I can run any linux box with full access to all my data, with the memory stick mounted on /home.

When I saw this problem come in, I was reminded of problems I have of elog crashing.  So I tried attaching a .bmp file to an entry.  In my case it did not crash, but it did not run ImageMagick either - it just gave a link as it it were a zip or tar file - that is to say no .png image had been generated and shown.   As I've never attached a .bmp file before, I don't know whether elog allows for them to be processed and a thumbnail made, a quick look in the documentation didn't enlighten me, but then I didn't look for that long either.  (I'm running 2.9.2 svn 2475, under Slackware 13 which is a version post some image processing issues I reported to Stefan - might that explain why in my case?). 

I have found that sometimes elog will crash, but effectively after it has done the action - so if it crashes when asked to move files from one logbook to another, you find the entries have been moved.  In my case, I believe the crashes are due to memory issues, nothing I can state for certain.

It would possibly help Stefan and Andreas if you can tell whether the .bmp file appears in the relivent logbook directory (usually a subdirectory of ....../logbooks) - it will have been renamed as yymmdd_hhmmss_{filename}.bmp - except, of course, the date and time will be showing not these symbols - and if the entry with which you have tried to attach this .bmp file been written - using a text viewer on the file yymmdda.log (obviously the day will be today, i.e. the one just updated as you tried the entry.   I have come across orphan attachment files in directories in my time, possibly from when elog crashed part way through an action.

(If I am stating the obvious, apologies, I don't know your level of experience with elog or linux, so trying to cover all possible levels)

 Hi David,

Which svn version of elog are you running - what does it say at the very bottom of the page (this forum says ELOG V2.9.0-2435); there *is* and issue about loading files and thumbnails with svn 2473, but it may also be in one or two prior to that (I found it with 2473, anyway).  Also, is elog running (taking CPU time) and not responding to anything after you try this (and you have to kill the daemon and restart), or crashing out at that point? I've had both behaviours at one time or another, for reasons I now understand, not related (I think) to this one, but the more evidence, the better chance that someone will find the problem.

David.

2455 is before the image handling issue came about, so it's nothing to do with those changes.

I see Andreas also finds that ImageMagick is apparently not invoked by elog to make a thumbnail of a .bmp file.  I tested it with a 5MB and a 0.5MB .bmp file this morning, so I don't really think it's the size of the file that is causing the problem - or that is my first guess, anyway.   But I suppose it is worth asking, what is the size of the .bmp file(s) you are trying to attach?  Just a thought, there is a parameter in the Global section of the elog.cfg - "Max Content Length".  I forget the default, I had to increase it when I wanted to attach a huge pdf file, wonder if that might be the issue (I had an error message come up with the pdf file, I wonder...)

The elog daemon can get stuck running like mad and not responding to anything.  One example I know is if you erase an elog entry (e.g. delete one file in the logbook directory, I'm not talking about using elog's own delete facility) the indexing of the entries is broken, and elog cannot handle that, it just gets stuck, consuming loads of CPU time doing I don't know what. 

I've got to go and do something in real life now, but I may get a chance to 'play' later, see if I hit any point that the experts can then work through

Hi Louis,

I'm a little surprised by your comment that you use symlinks 'to store your logbooks elsewhere'.

I start the daemon with

 /usr/local/sbin/elogd -p 8080 -c /home/logbooks/elogd.cfg -d /home/logbooks

so that both my logbooks *and* the config file are both based on my preferred location, which is a subdirectory of /home.  No symlinks  OK, themes are elsewhere, but for backup purposes, that's a rather lesser issue. 

I have no idea why the default logbook location is /usr/local/elog/logbooks which does not strike me as a sensible location (at least on Slackware).  Maybe such an odd location was to force users to choose a better location...(the -d switch).

To all:

I use Slackware (currently 13, I hear there are some issues with 14 for programs I wish use), and I compile from the sources.  Usually from random svn versions as a general pain-in-the-neck for Stefan.  I've never had to make a [Slackware] package for distribution - I have issued patches and/or source distribution, depending on your point of view.  If someone can provide the advice, I'd certainly try and do a Slackware distribution, but I do have Real Work to do as well, so it may not be done immediately.  I think Ubuntu is fairly close to Slackware, not sure about Debian, which I *thought* was close to Red Hat.

Now I *do* understand what some of the other contributors to this thread are doing, as I do something similar for other programs that are now unmaintained and no longer compile with GCC4 or earlier.  The email program I use is a ten-year-old binary & libraries I compiled under Slackware 7 (if not, 4), and I copy the relivent binaries, libraries and dependances across when I upgrade the o/s.  Yes, one day it will fall down.  Three other programs I regularly use are similarly now 'legacy'.  My 'C' coding isn't up to the major changes apparently needed to allow them to compile again with a modern compiler.