elogd 3.1.0 moves all elog entries into year-named subdirectories. this feature makes it incompatible with older elogs and so should be clearly mentioned in the documentation,
in the release announcement and in the release and migration notes. K.O.

> elogd 3.1.0 moves all elog entries into year-named subdirectories. this feature makes it incompatible with older elogs and so should be clearly mentioned in the documentation,
> in the release announcement and in the release and migration notes. K.O.

That feature is one of the main reasons why the version jumped from 2.x to 3.x. 
A free tip: changes in major revisions do indicate some kind of incompatibility.
But yes, the release documentation by bitbucket is not really that useful: 
it is difficult for me too, to find out what changed with new releases. 
I have to admit here, that I haven't read any GIT tutorial yet.
By the way: you are welcome to contribute to the release documentation!

On your actual problem: to go back to a former version of ELOG you can simply
- stop elogd 3.X, 
- move all entries from the sub-directories one level up, and 
- start the 2.X version of elogd.

I wouldn't really call this an "incompatibility", would you? 
At least you can easily go back without much trouble.

Cheers
Andreas

> > elogd 3.1.0 moves all elog entries into year-named subdirectories. this feature makes it incompatible with older elogs and so should be clearly mentioned in the documentation,
> > in the release announcement and in the release and migration notes. K.O.
> 
> That feature is one of the main reasons why the version jumped from 2.x to 3.x. 
> A free tip: changes in major revisions do indicate some kind of incompatibility.
> But yes, the release documentation by bitbucket is not really that useful: 
> it is difficult for me too, to find out what changed with new releases. 
> I have to admit here, that I haven't read any GIT tutorial yet.
> By the way: you are welcome to contribute to the release documentation!
> 
> On your actual problem: to go back to a former version of ELOG you can simply
> - stop elogd 3.X, 
> - move all entries from the sub-directories one level up, and 
> - start the 2.X version of elogd.
> 
> I wouldn't really call this an "incompatibility", would you? 
> At least you can easily go back without much trouble.
> 
> Cheers
> Andreas
Stefan told me that the change was because some users were having thousands of yymmdda.log files
in the logbook directories, and that sorting them into subdirectories by year at least did something to bring some 
order.  Possibly to get around the lazy archivers, I suspect.

When I first tried v3.0, I wanted to go back due to some bug or feature, and had to do exactly what Andreas suggested above.

David.

> Stefan told me that the change was because some users were having thousands of yymmdda.log files
> in the logbook directories, and that sorting them into subdirectories by year at least did something to bring some 
> order.  Possibly to get around the lazy archivers, I suspect.

I'm actually the culprit, who did ask for it.

If you want to know the full story, here it is:
We have our logbook data of our accelerator operation logbooks on AFS (Andrew File System). 
And apparently AFS has a bloody stupid, hard coded limit: 
the total length of all file names in one directory cannot exceed 64k.
Our operation logbooks go back for more than a decade and do contain many, many, many attachment files.
One day - very unexpectedly - we did hit that limit. 
Removing temporary files (generated picture thumbnails) bought us time, and Stefan was nice enough to upgrade ELOG swiftly for us: a big "Thank You" to Stefan!

> > Stefan told me that the change was because some users were having thousands of yymmdda.log files
> > in the logbook directories, and that sorting them into subdirectories by year at least did something to
bring some 
> > order.  Possibly to get around the lazy archivers, I suspect.
> 
> I'm actually the culprit, who did ask for it.
> 
> If you want to know the full story, here it is:
> We have our logbook data of our accelerator operation logbooks on AFS (Andrew File System). 
> And apparently AFS has a bloody stupid, hard coded limit: 
> the total length of all file names in one directory cannot exceed 64k.
> Our operation logbooks go back for more than a decade and do contain many, many, many attachment files.
> One day - very unexpectedly - we did hit that limit. 
> Removing temporary files (generated picture thumbnails) bought us time, and Stefan was nice enough to upgrade
ELOG swiftly for us: a big "Thank You" to Stefan!


Hi Andreas,

I had no intention of causing any offence with my lazy archiving comment - hope I didn't, sorry if I did.  Just
that sometimes I've hit some limit or other, and
entirely due to my lazy archiving - I only get around to do it when I have to, usually when I've hit a limit, or
some other problem (broken links and orphaned
threads being common ones).   

Personally, I would have found it useful to put the attachments into a separate directory - or at least to allow
the possibility.  Elog as it stands sometimes
can, and sometimes cannot cope with that functionality - and even to try means messing around directly with the
yymmdda.log files.  For me it would have saved me
having duplicates of the same large attachment in two or three different logbooks, if I could always reference
the same Master copy of the attachment.  This was
at the time I was severely memory constrained, and in part forced me to change how I had operated elog, so for
me that need isn't as great as it once was.

David.

I had no intention of causing any offence with my lazy archiving comment - hope I didn't, sorry if I did.

Personally, I would have found it useful to put the attachments into a separate directory - or at least to allow

the possibility. Elog as it stands sometimes can, and sometimes cannot cope with that functionality - and even to try means messing around directly with the

yymmdda.log files. For me it would have saved me having duplicates of the same large attachment in two or three different logbooks, if I could always reference

the same Master copy of the attachment. This was at the time I was severely memory constrained, and in part forced me to change how I had operated elog, so for

me that need isn't as great as it once was.

David.

You can put a reference to the attachment of the other entry in your logbook: elog:67896/1

> Stefan told me that the change was because some users were having thousands of yymmdda.log files
> in the logbook directories

I am one of those users. The elog for the ALPHA experiment at CERN goes back to 2006 or so,
with large volume of messages and huge number of attachments. The MIDAS forum elog goes back to 2003.
The TRIUMF DAQ internal elog goes back to 2001.

I think the new organization is an improvement.

K.O.

> > Stefan told me that the change was because some users were having thousands of yymmdda.log files
> > in the logbook directories
> 
> I am one of those users. The elog for the ALPHA experiment at CERN goes back to 2006 or so,
> with large volume of messages and huge number of attachments. The MIDAS forum elog goes back to 2003.
> The TRIUMF DAQ internal elog goes back to 2001.
> 
> I think the new organization is an improvement.
> 
> K.O.
Hi Konstantin,

I've used elog as my main reference/logbook since 2005.  I had looked at it in its version 1 incarnation, but
didn't get on with that so well.  

My biggest problem in the past was running elog on two physically separated linux boxes, and for complex reasons
all the logbooks were on a memory stick (plus the vital backup)!  Hence my previously mentioned memory issues - in
my case the size of the available memory sticks.
David.

> > elogd 3.1.0 moves all elog entries into year-named subdirectories. this feature makes it incompatible with older elogs and so should be clearly mentioned in the documentation,
> > in the release announcement and in the release and migration notes. K.O.
> 
> But yes, the release documentation by bitbucket is not really that useful: 
> it is difficult for me too, to find out what changed with new releases. 

I did know that I've read it summarized somewhere!
The changes with the different releases are documented here:
http://midas.psi.ch/elog/download/ChangeLog

It is actually not so difficult to find: 
it is linked on the "Download" section http://midas.psi.ch/elog/download.html

"News for each version can be seen in the changelog (->http://midas.psi.ch/elog/download/ChangeLog)"

And for version 3.0.0 it states:
- Create one logbook subdirectory pear year

I admit that version 3.0 has never been announced and the changelog is not mentioned in the announcement of version 3.1.0
Maybe we'll do better in the future ;-)

> 
> "News for each version can be seen in the changelog (->http://midas.psi.ch/elog/download/ChangeLog)"
> 
> And for version 3.0.0 it states:
> - Create one logbook subdirectory pear year
> 

The text should read:

the first time you run the new elogd against old elog data,
all existing entries will be moved into by-year subdirectories
and the old elogd will not work anymore.

K.O.

elogd is spewing these messages about unknown cookies:

Received unknown cookie "is_returning"
Received unknown cookie "__utma"
Received unknown cookie "__utmz"
Received unknown cookie "SSESSee3cc9c70bedf9a840203765bf409d7b"
Received unknown cookie "SESSee3cc9c70bedf9a840203765bf409d7b"
Received unknown cookie "MidasWikiUserID"
Received unknown cookie "MidasWikiUserName"
Received unknown cookie "MidasWiki_session"

K.O.

> elogd is spewing these messages about unknown cookies:
> 
> Received unknown cookie "is_returning"
> Received unknown cookie "__utma"
> Received unknown cookie "__utmz"
> Received unknown cookie "SSESSee3cc9c70bedf9a840203765bf409d7b"
> Received unknown cookie "SESSee3cc9c70bedf9a840203765bf409d7b"
> Received unknown cookie "MidasWikiUserID"
> Received unknown cookie "MidasWikiUserName"
> Received unknown cookie "MidasWiki_session"
> 
> K.O.

Delete your cookies ;-)

Elog just logs all unknown cookies for trouble shooting. This should go under verbose output. I changed that just now.

Stefan

> > elogd is spewing these messages about unknown cookies:
> > 
> > Received unknown cookie "is_returning"
> > Received unknown cookie "__utma"
> > Received unknown cookie "__utmz"
> > Received unknown cookie "SSESSee3cc9c70bedf9a840203765bf409d7b"
> > Received unknown cookie "SESSee3cc9c70bedf9a840203765bf409d7b"
> > Received unknown cookie "MidasWikiUserID"
> > Received unknown cookie "MidasWikiUserName"
> > Received unknown cookie "MidasWiki_session"
> > 
> > K.O.
> 
> Delete your cookies ;-)
> 

No, go. The MidasWikiUserName cookie will log me out of the MidasWiki, etc.

But why are MidasWiki cookies sent to the elog? Ah, yes, they all run from the same https://midas.triumf.ca.

This explains why elog complains about unexpected cookies - elogd does not expect to receive
mediawiki cookies - it does not expect to share the https:// connection with somebody else.

This is good to know for the future. (I.e. if mediawiki is confused by elogd cookies).

K.O.

Hi,

I am doing an inline image that is about 2.2 MB.  When I do a submit, I got the following message:

Error sending Email via <i>"<email server>"</i>: Entry size too large for email notification.

May I know what is the limit of the entry size and how do I change it?  Thank you.

Jacky

The size is defined by the variable MAX_CONTENT_LENGTH in elogd.c which is set to 10 MB. But email attachments are encoded in ASCII form, so they take useually 3-4 times the space of the binary format. If you have problems with large emails, you can use the option "Email Format = 111" which causes only the names of attachments to be included in email notifications. Users can then still click on the elog link inside the email notification and download the attachment from the elog page.

this elog gives errors sending mail through PSI email server. (did not capture the error messages, sorry). K.O.

I have to import a csv with a date field, which represents the creation date

this date should be used as "date" timestamp which is set automatically, otherwise all entries get the current datetime as timestamp

Thanks

what is the format of the Date field in the csv file ?

My Date is date and not datetime. 

I came accross the admin guide and I was reading / searching for a way to sync logbooks across sites...
elogd mention "-m" and "-M" ... not elog but elogd... with that description :
synchronize logbook(s) with remote server

Does it sync all logbooks ? is there any examples somewhere or advice ?

Thanks :)

> I came accross the admin guide and I was reading / searching for a way to sync logbooks across sites...
> elogd mention "-m" and "-M" ... not elog but elogd... with that description :
> synchronize logbook(s) with remote server

If you would have followed the shown link to the "elogd.cfg syntax page", you would have found the chapter Mirroring:
https://midas.psi.ch/elog/config.html#mirroring

> Does it sync all logbooks ? 

Not necessarily, but that is the default.

> is there any examples somewhere or advice ?

See above: you'll find examples under #mirroring

> Thanks :)

You're welcome.

I have a little problem with elogd 3.1.0. The problem persists up to the latest ELOG version, even in the
development branch (V3.1.0-8196b81):

When I want to "Submit" a new entry, I get a javascript pop-up that asks me:

_This page is asking you to confirm that you want to leave - data you have entered may not be saved._

with the options:
"Stay on page" or "Leave page".

The entry is properly submitted if I agree to "Leave page".
But it is very confusing for my users: they are afraid to loose their entry text.

This problem only shows for some specific logbook configurations.
Below is a minimal logbook configuration that shows this problem:
if you select "entry = short", the pop-up is shown;
if you select "entry = long", the pop-up is not shown, the entry is created immediately.

Attributes = entry, when
Options entry = short{1}, long
Type when = datetime
{1} Show Attributes Edit = entry


(PS: it took me several hours to boil down my 120 line configuration into four lines :-) )

Thanks for the "boiling-down" of your config file. That helped me to reproduce the error quickly. It only occurs if you have a date/time attribute which is hidden as a conditional attribute. This is a unusual combination, that's why I haven't seen that bug before. Actually some 
JavaScript code checks the validity of the date attribute, but since it is conditionally not there, the JavaScript code crashes, which triggers the dialog box you see. It's now fixed in the repository.

/Stefan


> I have a little problem with elogd 3.1.0. The problem persists up to the latest ELOG version, even in the
> development branch (V3.1.0-8196b81):
> 
> When I want to "Submit" a new entry, I get a javascript pop-up that asks me:
> 
> _This page is asking you to confirm that you want to leave - data you have entered may not be saved._
> 
> with the options:
> "Stay on page" or "Leave page".
> 
> The entry is properly submitted if I agree to "Leave page".
> But it is very confusing for my users: they are afraid to loose their entry text.
> 
> This problem only shows for some specific logbook configurations.
> Below is a minimal logbook configuration that shows this problem:
> if you select "entry = short", the pop-up is shown;
> if you select "entry = long", the pop-up is not shown, the entry is created immediately.
> 
> Attributes = entry, when
> Options entry = short{1}, long
> Type when = datetime
> {1} Show Attributes Edit = entry
> 
> 
> (PS: it took me several hours to boil down my 120 line configuration into four lines :-) )

> Thanks for the "boiling-down" of your config file. That helped me to reproduce the error quickly. It only occurs if you have a date/time attribute which is hidden as a conditional attribute. This is a unusual combination, that's why I haven't seen that bug before. Actually some 
> JavaScript code checks the validity of the date attribute, but since it is conditionally not there, the JavaScript code crashes, which triggers the dialog box you see. It's now fixed in the repository.
> 
> /Stefan
> 

Thank you Stefan!
That works nicely now.
Apparently it was less work to fix than to isolate it ;-)

Andreas

> Apparently it was less work to fix than to isolate it ;-)

Well, I also spend like an hour on it.

Hey,

I want to submit an entry to elog remotley using the "elog" command. For example:

elog -h elog-server-adress -l EO -a Fill=111

But this does not generate a new entry. Instead the terminal jumps to an empty new line and the command does not respond to any further inputs anymore (CTRL+C to get out). I have to add a message:

elog -h elog-server-adress -l EO -a Fill=111 "test"

also using an empty string does not work:

elog -h elog-server-adress -l EO -a Fill=111 ""

I could add a whitespace as a work-around, but I'm not sure if this is a bug or a feature.

To put this in some context: I want to create entries for certain measurements automatically, where all relevant parameters are already attribute fields. In the usual case the actual message will be empty but might be used if the operator wants to add a note after the meausrement has been done.

The "command does not respond" means that the program starts reading in the main message text from the console. You can type several lines of text, and finish it off by hitting Ctrl-D (Ctrl-Z under Windows).

I see your point of having empty texts. Indeed the "" on the command line does not work presently, so you have to add a space as a workaround. I modified the elog code (committeed to bitbucket repository) to accept "" as empty text to suit your needs.

/Stefan

Hi Edmund,

Stefan already supplied a fix, but you could as well use a workaround: provide an empty file as text. The following works for Linux:

elog -h elog-server-adress -l EO -a Fill=111 -m /dev/null