package/source/zipapi/XUnbufferedStream.cxx | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
New commits: commit 7425b7dce3945bb78f44e33f924a09fc44e05ea4 Author: Michael Stahl <[email protected]> AuthorDate: Wed Sep 24 18:28:25 2025 +0200 Commit: Michael Stahl <[email protected]> CommitDate: Tue Oct 14 12:16:57 2025 +0200 tdf#168538 package: downgrade assert to SAL_WARN It is only impossible during normal package parsing because of the added consistency checks, but the inconsistency can happen during recovery. Kind of arbitrary which size is used then? Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191455 Tested-by: Jenkins Reviewed-by: Michael Stahl <[email protected]> (cherry picked from commit 347512a77b2e627715e57d5731fe93836d103eb1) tdf#168538 package: now i notice there's bRecoveryMode Change-Id: I909ab70a97d6e89456d17a6804551abd618444a4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191737 Tested-by: Jenkins CollaboraOffice <[email protected]> Reviewed-by: Stephan Bergmann <[email protected]> diff --git a/package/source/zipapi/XUnbufferedStream.cxx b/package/source/zipapi/XUnbufferedStream.cxx index 192958412d93..8dfcf868f05c 100644 --- a/package/source/zipapi/XUnbufferedStream.cxx +++ b/package/source/zipapi/XUnbufferedStream.cxx @@ -67,7 +67,8 @@ XUnbufferedStream::XUnbufferedStream( { mnZipCurrent = maEntry.nOffset; sal_Int64 nSize; // data size in the zip file - assert(maEntry.nMethod != STORED || maEntry.nCompressedSize == maEntry.nSize); + // this can actually happen in recovery + assert(bRecoveryMode || maEntry.nMethod != STORED || maEntry.nCompressedSize == maEntry.nSize); if ( mbRawStream ) { mnZipSize = maEntry.nCompressedSize;
