A very common issue (watching the mailing list) is not wrapping the
whole configuration in a dictionary. SOGo is not very helpful at
debugging broken configuration files, thus hinting `plparse` already
installed with the GNUstep runtime.
By getting the root folder/container whose properties
are stored in OpenChange DB.
This makes the synchronisation of sub-folders faster as
when we evaluate restrictions for this folder, we are able
to get the modseq from where to get the latest messages
unseen by the client.
This may happen if between sync cache and setChangeKey a modSeq
is making synchroniseCache not retrieve the newly stored message.
This should fix the following crash:
https://tracker.zentyal.org/issues/2673
Valgrind crafted report:
=40967== 128,927 (53,750 direct, 75,177 indirect) bytes in 383 blocks are definitely lost in loss record 10,104 of 10,179
==40967== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==40967== by 0x86EDE3D: talloc_strndup (talloc.c:613)
==40967== by 0x34D2BB9E: _i_NSString_MAPIStoreDataTypes_asUnicodeInMemCtx_ (in /usr/lib/GNUstep/SOGo/SOGoBackend.MAPIStore/SOGoBackend)
==40967== by 0x34D2025B: _i_MAPIStoreMailMessage__getPidTagNormalizedSubject_inMemCtx_ (in /usr/lib/GNUstep/SOGo/SOGoBackend.MAPIStore/SOGoBackend)
==40967== by 0x34CFCD40: _i_MAPIStoreObject__getProperty_withTag_inMemCtx_ (in /usr/lib/GNUstep/SOGo/SOGoBackend.MAPIStore/SOGoBackend)
==40967== by 0x34CFBE21: _i_MAPIStoreMessage__getPidTagSubject_inMemCtx_ (in /usr/lib/GNUstep/SOGo/SOGoBackend.MAPIStore/SOGoBackend)
==40967== by 0x34CFBEB6: _i_MAPIStoreMessage__getPidTagOriginalSubject_inMemCtx_ (in /usr/lib/GNUstep/SOGo/SOGoBackend.MAPIStore/SOGoBackend)
==40967== by 0x34CFCD40: _i_MAPIStoreObject__getProperty_withTag_inMemCtx_ (in /usr/lib/GNUstep/SOGo/SOGoBackend.MAPIStore/SOGoBackend)
==40967== by 0x34CFD07E: _i_MAPIStoreObject__getProperties_withTags_andCount_inMemCtx_ (in /usr/lib/GNUstep/SOGo/SOGoBackend.MAPIStore/SOGoBackend)