> 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!

> > 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.

> 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.

this elog offers me to edit a draft message, then yells at me "only some other user can edit this draft!!!".
methinks I should only be offered to edit draft messages that I own or I can edit. K.O.

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

Converting from elog 2.9.something to new elog 3.1.0 elogd refuses to start, instructs running elconv in one logbook.

When I do so, elconv converts a existing mhttpd-style elog entries to the new format (the corresponding new-format entries already exist)
and deletes everything else - this is very bad.

So there are 2 bugs:
- elogd should not tell us to run elconv when both old-style and corresponding new-style elog entries exist
- elconv should not delete all existing new-style elog entries.

I confirm that elconv *does* delete all new-style elog entries - with strace, I see it issue "unlink" on every elog entry.

What a disaster!

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.