Commit a6ad198d09 made the size read
from the grabber wrong for the last chunk: it wasn't decreased to
the remaining size, but was still equal to nBlockSize. The grabber
could read past the chunk, and the CRC was wrong. No idea why did
that only hit this file - it seemed that any file larger than 32K
and that was stored (i.e., any image) would trigger that path?
Change-Id: I980dd701e54c4ed565173b5b90ed301bf9b5f719
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186241
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The PK78 signature is optional, and if the sizes in the local file
header are 0 then without the DD the recovery won't do anything useful.
If the latest local file header has the DD bit set in flags, then try to
find the DD before the next thing that has a PK?? signature.
Change-Id: I149a87805f7bcb6216fc909c20ece600ce77956d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183722
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
... compressed size = 0.
The problem is that vector::data() on a vector of size 0 returns
nullptr, and osl_readFile into a nullptr buffer returns E_INVAL, which
causes an exception to be thrown.
Catch the exception, so that there is a chance to read the values from
the data descriptor instead.
(regression from commit 32cad89592
and/or commit a6ad198d09)
Change-Id: I9b2d9a930997146faf224d8033955b142fe93f58
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176289
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
1. Accept 0xFFFF as nEndDisk/nEndDirDisk - the Zip APPNOTE says that
values that don't fit into 16 bits SHOULD be 0xFFFF but it doesn't
prohibit values that do fit (like, uhm, 0) to be written as 0xFFFF
(regression from commit ca21cc985d)
2. Fix misuse of o3tl::make_unsigned - it requires non-negative value,
just do signed compare instead
3. Fix bad conversion from pointer to optional in
ZipFile::readExtraFields() which effectively prevented the offset
from being read
(regression from commit efae4fc42d)
Change-Id: Ib5e7776a30834e507b297fb28266b5489d1ab68d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174898
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Bugdoc has a data descriptor on a folder entry, which is very odd and
entirely pointless. Which is also the first entry, so it's an invalid
ODF package anyway.
ZipPackageFolder throws UnknownPropertyException for "WasEncrypted",
which results in General I/O error, but we want to ask the user if the
file should be opened in recovery mode.
(regression from commit 32cad89592)
Change-Id: Iafe610d507cf92d2fd2e9c3040592c3e638a30dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174889
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Probably the only legitimate use of such is self-extracting archives,
irrelevant for LO.
ofz56826-1.zip is an example; given what Info-Zip unzip prints about
this file we don't want to successfully open it.
Change-Id: I9568710227e4a152f9dc7bc356184394d7da8eba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170002
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Implemented import + export for "Zip64 Extended Information Extra Field",
(in "Local file header" and "Central directory file header")
and for Data descriptor.
Focused only to be able to handle files with over 4GB uncompressed size,
in the zip archive.
The 64k filecount, and the 4GB compressed size limit is probably still present
Tried to follow pkware .ZIP File Format Specification,
Some cases were not clear to me and/or some zip compressing tool may not
perfectly follow the standard, like 'extra field' should be 28 bytes long,
but its reader now can read shorter (or longer) 'extra field'.
Replaced some 32bit codes with 64bit codes, in stream handling, in deflater.
Tested with an ods file that contained a content.xml that bigger then 4BG+
(import + export + reimport) on windows.
I think 4GB+ files import/export would be too slow fot unittest.
So, for unit test, used the small but zip64 format files,
that was attached to the bugzilla tickets
Note: It helps with Bug 128244 too (1 of the unittest tests it),
but that ods file missing manifest.xml, so LO won't be able to import it.
Change-Id: Idfeb90594388fd34ae719677f5d268ca9a484fb1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147306
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
It started out as a wrapper around character literals, but has by now become a
wrapper around arbitrary single characters. Besides updating the documentation,
this change is a mechanical
for i in $(git grep -Fl OUStringLiteral1); do sed -i -e s/OUStringLiteral1/OUStringChar/g "$i"; done
Change-Id: I1b9eaa4b3fbc9025ce4a4bffea3db1c16188b76f
Reviewed-on: https://gerrit.libreoffice.org/80892
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
which defeat the *StringConcat optimisation.
Also make StringConcat conversions treat a nullptr as an empty string,
to match the O*String(char*) constructors.
Change-Id: If45f5b4b6a535c97bfeeacd9ec472a7603a52e5b
Reviewed-on: https://gerrit.libreoffice.org/80724
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Since it is now possible to use C++14, it's time to replace
the temporary solution with the standard one
Change-Id: I8bee1344f7df82536f31bc5e4ec4fd379cac1d04
Reviewed-on: https://gerrit.libreoffice.org/66704
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
And fix leak in XclExpRowBuffer::Finalize, was not freeing the
synchronous task it creates
Change-Id: Id1e9ddb5d968e6b95d9d2b5ca0c9e50774580182
Reviewed-on: https://gerrit.libreoffice.org/56874
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
As it causes "unopkg.bin:
/home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/comphelper/source/misc/threadpool.cxx:96:
comphelper::ThreadPool::~ThreadPool(): Assertion `mbTerminate' failed."
in
<https://ci.libreoffice.org/job/lo_gerrit/8283/Config=linux_clang_dbgutil_64/console>
and also locally. Revert till it's clear if that assert() should be a
SAL_WARN() or unopkg has to be fixed.
This reverts commit 9899ffd244.
Change-Id: I72902f7da410012340aa8231d84c6871a3f7b976
Commit aa68c99d88 added some code using
std::condition_variable to comphelper.
Built with MSVC 2017, this causes many cppunittester.exe processes to
deadlock in ThreadPool::shutdown():
maTasksChanged.notify_all();
This ultimately calls NtReleaseKeyedEvent(), which never returns.
The reason appears to be a bug in Windows 7, for which a "hotfix"[1] is
avaiable here, but it's apparently not distributed via Windows Update
so we likely can't rely on users or even developers having this installed.
However, the documentation of DllMain[2] and ExitProcess[3] indicates
that during shutdown, by the time global destructors are invoked
all threads other than the one that called ExitProcess have already
been terminated.
Returning from main() implicitly calls ExitProcess [4].
As it turns out the problem only happens for some CppUnitTests because
soffice.bin will call ThreadPool::shutdown() from Desktop::doShutdown()
while it is still safe.
[1] http://support.microsoft.com/kb/2582203
[2] https://msdn.microsoft.com/en-US/library/windows/desktop/ms682583(v=vs.85).aspx
[3] https://msdn.microsoft.com/en-us/library/windows/desktop/ms682658(v=vs.85).aspx
[4] https://blogs.msdn.microsoft.com/oldnewthing/20100827-00/?p=13023
Change-Id: I6137461ca7efe9a5fbe4f8f8478fb96de3570469
Reviewed-on: https://gerrit.libreoffice.org/35066
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
(as some tests derive from the latter only for the Directories part, not for the
setUp/tearDown overrides: those tests will be cleaned up next)
Change-Id: Ib6b78eea868b8bc21d4cc6e8fd9e1d025deca05f
Reviewed-on: https://gerrit.libreoffice.org/23078
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
of which there are several.
There are some issues here I am unsure of
- the SW and SC and CHART2 modules essentially ignore the enum values and assign their own ids
Perhaps I should change them to use the common values and create new enum values where necessary?
- the sc/qa/ and sq/qa/ and starmath/qa/ code was doing some dodgy stuff. I translated the code to pass down the stuff
numeric values to the underlying code, but perhaps further fixing is necessary?
Change-Id: Ic06d723e404481e3f1bca67c43b70321b764d923
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: I71fa20213e86be10de332ece0aa273239df7b61a
Mike Kaganski