3.6.0 regression: non-deterministic filter selection ...
timofeev.i.s at gmail.com
Wed Aug 15 10:19:47 PDT 2012
On 15.08.2012 21:00, Kohei Yoshida wrote:
> On 08/15/2012 12:26 PM, Kohei Yoshida wrote:
>> On 08/15/2012 12:12 PM, Kohei Yoshida wrote:
>>> Ah. Now I know. Ultimately the failure is due to StgHeader::Check()
>>> returning false on Large-Word.doc.
>>> Changing this method to always return true leads to Writer loading the
>>> file correctly.
>> And the check that fails is this:
>> ( nMasterChain == -2 || ( nMasterChain >=0 && nMaster > 109 ) )
>> where nMasterChain == 24269 and nMaster == 2. Since nMaster > 109 is
>> false, it returns false, and the whole thing starts to crumble...
> So, we have a choice to make. This patch
> diff --git a/sot/source/sdstor/stgelem.cxx b/sot/source/sdstor/stgelem.cxx
> index 5fb3a09..dfcc28a 100644
> --- a/sot/source/sdstor/stgelem.cxx
> +++ b/sot/source/sdstor/stgelem.cxx
> @@ -194,7 +194,7 @@ sal_Bool StgHeader::Check()
> && nTOCstrm >= 0
> && nThreshold > 0
> && ( nDataFAT == -2 || ( nDataFAT >= 0 && nDataFATSize > 0
> ) )
> - && ( nMasterChain == -2 || ( nMasterChain >=0 && nMaster >
> 109 ) )
> + && ( nMasterChain == -2 || nMasterChain >=0 )
> && nMaster >= 0;
> which removes the check for nMaster being greater than 109 fixes this
> load issue.
> The documentation:
> basically says that number represents the number of DIFAT sectors that
> follows, and the number of the DIFAT sectors is always 109. That's
> probably where the check came from (though strictly the check should be
> nMaster == 109 instead of nMaster > 109).
> But we always load 109 DIFAT sectors regardless of the value of nMaster,
> and nMaster *may* actually represents the number of *used* DIFAT
> sectors... Who knows? The documentation is not very clear about this.
first 109 sectors are in the header anyway and nMaster are in FAT (if
needed). nMaster should not be checked for 109.
More information about the LibreOffice