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.

I've just noticed that it has also sorted another Option, which are selected as radio buttons.  Again, this is a
list which has a natural - again, in this case, chronological - order.

Because of this, I'm going to have to turn off this feature as it is on my system.  I hope something can be sorted
on this.


> (For some reason I could not add this in Dennis's thread.)
> 
> I like this new feature, BUT
> 
> I happen to have two Options:   Options System, and Options Status.
> 
> System are a very few items, whereas Status has a long list, which, like Dennis's example, can be added to. 
> Keeping the latter in alpha order is great, but it's a shame that the cost is that Options System are also
> sorted alphabetically, whereas it has a natural order which it would be preferable to keep - for example (and
> this is made up)
> 
> Options System: 3.1, NT, 2000, XP, Vista
> 
> where the natural order here is chronological.
> 
> Perhaps the configuration file option could be more specific, for example
> 
> Sort attribute Options Status = 1
> 
> which would then NOT sort Options System.  If both are needed to be sorted, both should be specified, or back to
> the original syntax which defaults to sort *all* Options.

Ok, that makes sense, so I changed it to

Sort Attribute Options Status = 1

as you suggested.

> (For some reason I could not add this in Dennis's thread.)
> 
> I like this new feature, BUT
> 
> I happen to have two Options:   Options System, and Options Status.
> 
> System are a very few items, whereas Status has a long list, which, like Dennis's example, can be added to. 
> Keeping the latter in alpha order is great, but it's a shame that the cost is that Options System are also
> sorted alphabetically, whereas it has a natural order which it would be preferable to keep - for example (and
> this is made up)
> 
> Options System: 3.1, NT, 2000, XP, Vista
> 
> where the natural order here is chronological.
> 
> Perhaps the configuration file option could be more specific, for example
> 
> Sort attribute Options Status = 1
> 
> which would then NOT sort Options System.  If both are needed to be sorted, both should be specified, or back to
> the original syntax which defaults to sort *all* Options.

Thanks Stefan!  Works great.

> Ok, that makes sense, so I changed it to
> 
> Sort Attribute Options Status = 1
> 
> as you suggested.
> 
> > (For some reason I could not add this in Dennis's thread.)
> > 
> > I like this new feature, BUT
> > 
> > I happen to have two Options:   Options System, and Options Status.
> > 
> > System are a very few items, whereas Status has a long list, which, like Dennis's example, can be added to. 
> > Keeping the latter in alpha order is great, but it's a shame that the cost is that Options System are also
> > sorted alphabetically, whereas it has a natural order which it would be preferable to keep - for example (and
> > this is made up)
> > 
> > Options System: 3.1, NT, 2000, XP, Vista
> > 
> > where the natural order here is chronological.
> > 
> > Perhaps the configuration file option could be more specific, for example
> > 
> > Sort attribute Options Status = 1
> > 
> > which would then NOT sort Options System.  If both are needed to be sorted, both should be specified, or back to
> > the original syntax which defaults to sort *all* Options.

Yes, many thanks, Stefan, from me, too! It's really great that you respond so quickly to requests and suggestions.

And thanks to David for the fine tuning, great suggestion.

Dennis

> Thanks Stefan!  Works great.
> 
> > Ok, that makes sense, so I changed it to
> > 
> > Sort Attribute Options Status = 1
> > 
> > as you suggested.
> > 
> > > (For some reason I could not add this in Dennis's thread.)
> > > 
> > > I like this new feature, BUT
> > > 
> > > I happen to have two Options:   Options System, and Options Status.
> > > 
> > > System are a very few items, whereas Status has a long list, which, like Dennis's example, can be added to. 
> > > Keeping the latter in alpha order is great, but it's a shame that the cost is that Options System are also
> > > sorted alphabetically, whereas it has a natural order which it would be preferable to keep - for example (and
> > > this is made up)
> > > 
> > > Options System: 3.1, NT, 2000, XP, Vista
> > > 
> > > where the natural order here is chronological.
> > > 
> > > Perhaps the configuration file option could be more specific, for example
> > > 
> > > Sort attribute Options Status = 1
> > > 
> > > which would then NOT sort Options System.  If both are needed to be sorted, both should be specified, or back to
> > > the original syntax which defaults to sort *all* Options.

All over sudden gcc comes with its own version of "strlcpy", which I had defined "manually" since many years inside ELOG. Using -DFORTIFY_SOURCE=0 will not harm, so you can use it. The "real" solution is to take our ELOG's strlcpy/strlcat, which I did on the current SVN version.

Best regards,
Stefan