This was already fixed in Git by:

https://github.com/horde/horde/commit/cc36df08d3aef06b72b00831ed82384f7e38461a

Related to Bug: 14201

Hi Mike,

confirmed :-)

- applied the path
- horde-clear-cache
- logoff/logon
- modified and successfully saved the changed event

Thank you for following up!

case closed :)

Regards,
Jens

Hi Jens,

I looked once more.

The patch I referenced below does fix *reading* base64 encoded Kolab 
XML objects.

The patch that fixes / works around saving those is actually another one. See:
https://bugs.horde.org/ticket/14201

Mike

The same test should be run with the Null driver for Horde Caching 
(i.e. Horde Caching disabled). Personally, I don't 100% trust 
horde-clear-cache in relation with Kolab.

First, check if the issue is still present with Horde_Caching using 
the Null driver.

Then check if applying the patch fixes the issue.

Also, please verify on your IMAP server the underlying mail object. 
What is the Kolab XML object's transfer encoding? If you decode the 
attachemnt manually, do Umlauts look correct?

Hi Mike,
- applied patch
- ran "horde-clear-cache"
- logged off, then on again
- tried to modify a calendar entry
- same error pop-up as usual:

--- cut here ---
Failed writing the Kolab object: Failed parsing Kolab object input 
data of type string! Input was: Æioz»"¢}tzw(v)àQ1|z÷§¶÷«²*'×K¢wž¸q½... 
[shortened to 50 characters]
--- cut here ---

I hope to have some time starting next year to set up a new test bed 
and really dig into this.

Regards,
Jens

Hi Jens,
Please check if the patch attached to [1] fixes your issue.

Greets,
Mike

[1] https://bugs.horde.org/ticket/14199

*** Could someone please give me a helping hand? ***

I have a trace... but am unsure if I'm on the right track.

- ran horde-clear-cache; imp-query-cache (clearing Kolab cache); rm 
$tmpdir/cache/horde*;rcapache2 restart
   (should have a clean system now)
- log in to Horde, then look at my debug log

I see that Horde_Kolab_Storage_Data_Base:modify() is called, sets the 
driver and then calls "$object->save($writer);", which does not throw 
an exception
  (looking at the IMAP store shows that a new config object for 
application "horde" is written)

but Horde_Prefs->store() reports an exception (see below for details)!

I've traced things back to Horde_Kolab_Storage_Cache_Data->store(), 
where it's running

                 if (isset($object['_attachments'])) {
                     $attachments = array();
Horde::debug($object);
                     foreach ($object['_attachments'] as $id => $attachment) {
                         $attachments['id'][] = $id;
                         if (isset($attachment['name'])) {
                             $attachments['name'][$attachment['name']][] = $id;
                         }
                         if (isset($attachment['type'])) {
                             $attachments['type'][$attachment['type']][] = $id;
                         }
                         
$this->_cache->storeAttachment($this->getDataId(), $obid, $id, 
$attachment['content']);
                     }
                     $object['_attachments'] = $attachments;
                 }
                 $this->_data[self::OBJECTS][$object['uid']] = $object;

storeAttachment($data_id, $obid, $attachment_id, $data) calls new 
Horde_Stream_Existing(array('stream' => $data)), which throws the 
exception

object(InvalidArgumentException)#3389 (7) {
   ["message":protected]=>
   string(23) "Need a stream resource."
   ["string":"Exception":private]=>
   string(0) ""
   ["code":protected]=>
   int(0)
   ["file":protected]=>
   string(46) "/usr/share/php5/PEAR/Horde/Stream/Existing.php"
   ["line":protected]=>
   int(39)

because of the following check:

     public function __construct(array $opts = array())
     {
         if (!isset($opts['stream']) || !is_resource($opts['stream'])) {
             throw new InvalidArgumentException('Need a stream resource.');
         }

Hence the Horde::debug( $object) in the code snipplet above and I have 
debugged the storeAttachment() params, too:

parm1 (data_id) is "35cc31fb3bdf4fb8afc81dba6f09c17a"
parm2 (obid) is 9764
parm3 (attachment_id) is "id"
parm4 (data) is... empty.

The object that  is looping over has the following _attachments content:

     ["_attachments"]=>
     array(2) {
       ["id"]=>
       array(3) {
         [0]=>
         string(27) "Kolab Groupware Information"
         [1]=>
         string(2) "id"
         [2]=>
         string(4) "type"
       }
       ["type"]=>
       array(2) {
         ["text/plain"]=>
         array(1) {
           [0]=>
           string(27) "Kolab Groupware Information"
         }
         ["application/octet-stream"]=>
         array(2) {
           [0]=>
           string(2) "id"
           [1]=>
           string(4) "type"
         }
       }
     }

"id" and "type" have completely different structures, is that intended?

The exceptions call trace is
/usr/share/php5/PEAR/Horde/Kolab/Storage/Cache/Data.php:493
/usr/share/php5/PEAR/Horde/Kolab/Storage/Data/Cached.php:252
/usr/share/php5/PEAR/Horde/Kolab/Storage/Data/Base.php:327
/usr/share/php5/PEAR/Horde/Prefs/Storage/KolabImap.php:141
/usr/share/php5/PEAR/Horde/Prefs.php:439

but I guess the entries are created somewhere else.

HELP!

rats - I cannot get back to my old identity settings any easy way - it 
seems I'll have to redo *all* configuration.

What I tried was:

- delete the new, limited horde config object from IMAP store
- log off from Horde
- remove the single cache object that holds the user configuration 
(it's a single file)
- log in

I then was able to a a single new identity, but not more than that.

My only way to get to add all my three identities seems to be to 
delete *all* preferences from IMAP, log off and start all over. Not 
good.

new detail:

while trying to locate the "load preferences" part of the source code, 
I logged off, then ran "horde-clear-cache" and then re-logged in.

Application:horde preferences were stored - and they were stored as 
quoted-printable, not as base64.

Unfortunately, these preferences were just "default" ones - at least 
not those that I had available until a few minutes ago.

And they received a new uuid - so the old prefs are still available as 
an IMAP message, but as an older one. And I see no way of re-estating 
the old preferences - deleting the cache will generate new ones.

Is it correct to assume that Horde preferences are read from the Horde 
cache (if available), rather than from the Kolab storage on every login?

My assumption given on the mailing list still holds true: This has 
somehow to do with Horde caching.

Hi Thomas,

pardon me for not catching that subtle notion earlier:
the *previous* XML data stream... now *that* makes sense :) Unlike my 
earlier comment, which now doesn't make sense :(

So I'm back to my earlier assumption: Maybe Horde has difficulties as 
the IMAP message attachment is base64-encoded, and does (for some 
reason) not decode it, but rather ignores it?

Where would I have to poke the source so see what it's reading and 
where it's (not) decoding the content?

Regards,
Jens

Hi Thomas,
ups - I saw you mentioned as author in various files of the Kolab 
sub-module, hence me contacting you...
Unfortunately, I'm unfamiliar with the inner workings of Horde. I 
wasn't able to spot the code where the $object from 
Horde_Kolab_Storage_Data_Base->modify() (which looks good in my trace, 
in all cases) is to be transformed into the "stream" that later is 
read in Horde_Kolab_Format_Xml_Parser->parse()

Do you have a hint for me, where I should add my next Horde::debug() call?
The XML generated on initial configuration looks good. The only 
noticeable difference is that the XML for application:horde is stored 
base64-encoded:

Content-Type: application/x-vnd.kolab.h-prefs; name=kolab.xml
Content-Disposition: inline; x-kolab-type=xml; filename=kolab.xml
Content-Transfer-Encoding: base64

while all other configuration objects are stored as

Content-Type: application/x-vnd.kolab.h-prefs; name=kolab.xml
Content-Disposition: inline; x-kolab-type=xml; filename=kolab.xml
Content-Transfer-Encoding: quoted-printable

But I haven't seen any immediate clue in the base64-decoded XML as of 
*why* this might be required.

Nevertheless, $object does carry what looks to me like a valid config 
(non-XML, of course) in Horde_Kolab_Storage_Data_Base->modify(), for 
all calls (imp/horde/...) alike.

Regards,
Jens

Hi Jens,

I haven't used the Kolab-based prefs backend myself.

To continue the debugging route, I would try to pin down
*why* the previous XML data stream is empty. For some reason
it probably didn't find the Kolab XML attachment or ignored it.

As you say storing and loading prefs for other applications work,
do you see any obvious difference in the generated XML data on the 
IMAP server?

Cheers,
Thomas

Horde is installed via PEAR and should be at the latest level:

  # pear list -c horde
Installed packages, channel pear.horde.org:
===========================================
Package                      Version State
Horde_ActiveSync             2.24.1  stable
Horde_Alarm                  2.2.4   stable
Horde_Argv                   2.0.10  stable
Horde_Auth                   2.1.6   stable
Horde_Autoloader             2.1.0   stable
Horde_Browser                2.0.8   stable
Horde_Cache                  2.5.0   stable
Horde_Cli                    2.0.6   stable
Horde_Compress               2.0.8   stable
Horde_Compress_Fast          1.1.0   stable
Horde_Constraint             2.0.2   stable
Horde_Controller             2.0.2   stable
Horde_Core                   2.19.0  stable
Horde_Crypt                  2.5.3   stable
Horde_Crypt_Blowfish         1.0.3   stable
Horde_CssMinify              1.0.2   stable
Horde_Css_Parser             1.0.6   stable
Horde_Data                   2.1.1   stable
Horde_Date                   2.0.13  stable
Horde_Date_Parser            2.0.3   stable
Horde_Dav                    1.1.2   stable
Horde_Db                     2.2.2   stable
Horde_Editor                 2.0.4   stable
Horde_ElasticSearch          1.0.3   stable
Horde_Exception              2.0.5   stable
Horde_Feed                   2.0.3   stable
Horde_Form                   2.0.9   stable
Horde_Group                  2.0.4   stable
Horde_HashTable              1.2.2   stable
Horde_History                2.3.3   stable
Horde_Http                   2.1.3   stable
Horde_Icalendar              2.0.10  stable
Horde_Idna                   1.0.1   stable
Horde_Image                  2.2.0   stable
Horde_Imap_Client            2.26.1  stable
Horde_Imsp                   2.0.6   stable
Horde_Injector               2.0.4   stable
Horde_Itip                   2.0.7   stable
Horde_JavascriptMinify       1.1.2   stable
Horde_JavascriptMinify_Jsmin 1.0.1   stable
Horde_Kolab_Format           2.0.6   stable
Horde_Kolab_Server           2.0.3   stable
Horde_Kolab_Session          2.0.2   stable
Horde_Kolab_Storage          2.1.2   stable
Horde_Ldap                   2.3.0   stable
Horde_ListHeaders            1.2.1   stable
Horde_Lock                   2.1.1   stable
Horde_Log                    2.1.1   stable
Horde_LoginTasks             2.0.4   stable
Horde_Mail                   2.5.1   stable
Horde_Mail_Autoconfig        1.0.2   stable
Horde_Mapi                   1.0.4   stable
Horde_Memcache               2.0.7   stable
Horde_Mime                   2.7.0   stable
Horde_Mime_Viewer            2.0.8   stable
Horde_Mongo                  1.0.3   stable
Horde_Nls                    2.0.5   stable
Horde_Notification           2.0.2   stable
Horde_Oauth                  2.0.2   stable
Horde_OpenXchange            1.0.0   stable
Horde_Pack                   1.0.5   stable
Horde_Pdf                    2.0.4   stable
Horde_Perms                  2.1.3   stable
Horde_Prefs                  2.7.2   stable
Horde_Queue                  1.1.2   stable
Horde_Rdo                    2.0.3   stable
Horde_Role                   1.0.1   stable
Horde_Routes                 2.0.3   stable
Horde_Rpc                    2.1.3   stable
Horde_Scribe                 2.0.2   stable
Horde_Secret                 2.0.4   stable
Horde_Serialize              2.0.3   stable
Horde_Service_Facebook       2.0.7   stable
Horde_Service_Gravatar       1.0.0   stable
Horde_Service_Twitter        2.1.2   stable
Horde_Service_Weather        2.1.5   stable
Horde_SessionHandler         2.2.4   stable
Horde_Share                  2.0.6   stable
Horde_Smtp                   1.8.0   stable
Horde_Socket_Client          1.1.2   stable
Horde_SpellChecker           2.1.2   stable
Horde_Stream                 1.6.2   stable
Horde_Stream_Filter          2.0.3   stable
Horde_Stream_Wrapper         2.1.2   stable
Horde_Stringprep             1.0.1   stable
Horde_Support                2.1.2   stable
Horde_SyncMl                 2.0.5   stable
Horde_Template               2.0.2   stable
Horde_Test                   2.5.0   stable
Horde_Text_Diff              2.1.1   stable
Horde_Text_Filter            2.2.2   stable
Horde_Text_Filter_Jsmin      1.0.1   stable
Horde_Text_Flowed            2.0.2   stable
Horde_Thrift                 2.0.2   stable
Horde_Timezone               1.0.9   stable
Horde_Token                  2.0.6   stable
Horde_Translation            2.2.0   stable
Horde_Tree                   2.0.3   stable
Horde_Url                    2.2.4   stable
Horde_Util                   2.5.2   stable
Horde_Vfs                    2.2.1   stable
Horde_View                   2.0.4   stable
Horde_Xml_Element            2.0.2   stable
Horde_Xml_Wbxml              2.0.2   stable
content                      2.0.4   stable
gollem                       3.0.3   stable
horde                        5.2.4   stable
horde_lz4                    1.0.7   stable
imp                          6.2.7   stable
ingo                         3.2.4   stable
kronolith                    4.2.5   stable
mnemo                        4.2.4   stable
nag                          4.2.4   stable
timeobjects                  2.1.0   stable
trean                        1.1.1   stable
turba                        4.2.5   stable
webmail                      5.2.4   stable

as you probably have noticed on the Horde mailing list, I ran into 
problems storing Horde preferences in our Kolab backend.

Yesterday, I have done some tracing in the Horde code, and pin-pointed 
the path leading to the problem. But I'm still far from solving the 
riddle and ask for your help.

The symptom is that Horde prefs (the ones for 
"<application>horde</application>", vs. i.e. 
"<application>imp</application>") are not *updated* in the IMAP store. 
Initial save works, but once the settings are stored, no new settings 
will be persisted.

Using the web UI, I receive the green "OK" feedback when storing these 
preferences... but further debugging showed that an exception is 
thrown, which somewhere along the way is caught and not reported 
"upstream":

--- cut here ---
2015-02-16T18:07:06+01:00 DEBUG: Variable information:
object(Horde_Kolab_Storage_Object_Exception)#984 (10) {
   ["details"]=>
   NULL
   ["logged"]=>
   bool(false)
   ["_logLevel":protected]=>
   int(0)
   ["message":protected]=>
   string(99) "Failed writing the Kolab object: Failed parsing Kolab 
object input data of type string! Input was:
"
   ["string":"Exception":private]=>
   string(0) ""
   ["code":protected]=>
   int(0)
   ["file":protected]=>
   string(65) 
"/usr/share/php5/PEAR/Horde/Kolab/Storage/Object/Writer/Format.php"
   ["line":protected]=>
   int(94)
   ["trace":"Exception":private]=>
   array(5) {
     [0]=>
     array(6) {
       ["file"]=>
       string(51) "/usr/share/php5/PEAR/Horde/Kolab/Storage/Object.php"
       ["line"]=>
       int(443)
       ["function"]=>
       string(4) "save"
       ["class"]=>
       string(40) "Horde_Kolab_Storage_Object_Writer_Format"
[...]
--- cut here ---


I found that exception by entering successive trace points in the code 
and then adding a "try/catch" block in Storage/Data/Base.php, method 
modify():

--- cut here ---
         if (!$object instanceOf Horde_Kolab_Storage_Object) {
             $object_array = $object;
             $object = $oldObject;
             $object->setData($object_array);
         }

         $object->setDriver($this->_driver);
         try {
         $result = $object->save($writer);
         } catch (Horde_Kolab_Storage_Exception $e) {
Horde::debug( $e);
         }
--- cut here ---

Further debugging brought me to Kolab/Format/Xml.php, method save():

--- cut here ---
     public function save($object, $options = array())
     {
Horde::debug( $object);
         if (!isset($options['previous'])) {
             $this->_xmldoc = $this->_getParser()->getDocument();
         } else {
             $parse_options = $options;
             unset($parse_options['previous']);
Horde::debug( $options);
             $this->_xmldoc = $this->_getParser()->parse(
                 $options['previous'], $parse_options
             );
Horde::debug( "TP0c");
         }
         $this->_refreshParser();
--- cut here ---

I hit both the first and second trace point, but not the third 
("TP0c"), hence the exception seems to be thrown in 
$this->_getParser()->parse().

That parse() method receives two arguments, $options['previous'] and 
$parse_options (which is $options minus $options['previous'], $options 
is traced as:

-- cut here ---
2015-02-16T18:07:06+01:00 DEBUG: Variable information:
array(1) {
   ["previous"]=>
   resource(7460) of type (stream)
}

Backtrace:
1. Horde_Prefs->store()
2. Horde_Prefs_Storage_KolabImap->store() 
/usr/share/php5/PEAR/Horde/Prefs.php:433
3. Horde_Kolab_Storage_Data_Base->modify() 
/usr/share/php5/PEAR/Horde/Prefs/Storage/KolabImap.php:137
4. Horde_Kolab_Storage_Object->save() 
/usr/share/php5/PEAR/Horde/Kolab/Storage/Data/Base.php:303
5. Horde_Kolab_Storage_Object_Writer_Format->save() 
/usr/share/php5/PEAR/Horde/Kolab/Storage/Object.php:443
6. Horde_Kolab_Format_Xml->save() 
/usr/share/php5/PEAR/Horde/Kolab/Storage/Object/Writer/Format.php:92
7. Horde::debug() /usr/share/php5/PEAR/Horde/Kolab/Format/Xml.php:271
--- cut here ---

The stream is read in parse() (but empty?) and at last _parseXml() 
receives that empty string as first parameter:

--- cut here ---
2015-02-16T18:28:10+01:00 DEBUG: Variable information:
string(0) ""

Backtrace:
1. Horde_Prefs->store()
2. Horde_Prefs_Storage_KolabImap->store() 
/usr/share/php5/PEAR/Horde/Prefs.php:433
3. Horde_Kolab_Storage_Data_Base->modify() 
/usr/share/php5/PEAR/Horde/Prefs/Storage/KolabImap.php:137
4. Horde_Kolab_Storage_Object->save() 
/usr/share/php5/PEAR/Horde/Kolab/Storage/Data/Base.php:302
5. Horde_Kolab_Storage_Object_Writer_Format->save() 
/usr/share/php5/PEAR/Horde/Kolab/Storage/Object.php:443
6. Horde_Kolab_Format_Xml->save() 
/usr/share/php5/PEAR/Horde/Kolab/Storage/Object/Writer/Format.php:92
7. Horde_Kolab_Format_Xml_Parser->parse() 
/usr/share/php5/PEAR/Horde/Kolab/Format/Xml.php:274
8. Horde_Kolab_Format_Xml_Parser->_parseXml() 
/usr/share/php5/PEAR/Horde/Kolab/Format/Xml/Parser.php:81
9. Horde::debug() /usr/share/php5/PEAR/Horde/Kolab/Format/Xml/Parser.php:114
--- cut here ---

which is generated in Format/Xml/Parser.php:
--- cut here ---
private function _parseXml($input, $options = array())
     {
Horde::debug( $input);
--- cut here ---

When storing other applications' preferences, data can be read from 
the according stream.

I have no idea how to continue from here. Can you make anything from 
this and share either a fix or at least a pointer to where I should 
continue debugging?

Not reporting the exception, but rather telling the user that saving 
the prefs was successful, is an error on its own ;)

Regards,
Jens