Bug 94915 - FILEOPEN: unable to open particular document apparently compressed with zip64 format - comment 8
Summary: FILEOPEN: unable to open particular document apparently compressed with zip64...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
3.5.0 release
Hardware: All All
: medium normal
Assignee: Attila Szűcs
Whiteboard: target:7.6.0
Keywords: filter:docx
Depends on:
Blocks: DOCX-Opening
  Show dependency treegraph
Reported: 2015-10-09 15:25 UTC by gabriel.sandor
Modified: 2023-04-24 20:30 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

DOCX file with dirty field originally created in MS Word that can not be opened by LibreOffice Writer. (10.08 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2015-10-09 15:25 UTC, gabriel.sandor

Note You need to log in before you can comment on or make changes to this bug.
Description gabriel.sandor 2015-10-09 15:25:02 UTC
Created attachment 119460 [details]
DOCX file with dirty field originally created in MS Word that can not be opened by LibreOffice Writer.

According to section 17.16.14 in ECMA-376 part 1 (http://www.ecma-international.org/publications/standards/Ecma-376.htm), fields can be marked with the w:dirty attribute which marks the field's contents as out-of-date when the attribute is set to "true".

Sometimes, when a dirty field exists in a .docx file, LibreOffice Writer fails to open it even if it is perfectly valid, throwing a "General error" message to the user. This can happen both for simple and complex fields.

MS Word, on the other hand, can always open such files.
Comment 1 Buovjaga 2015-10-09 16:41:13 UTC
The file '_Author.docx' is corrupt and therefore cannot be opened. LibreOffice can try to repair the file.

Win 7 Pro 64-bit, Version: (x64)
Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe
Locale: fi-FI (fi_FI)

Build ID: f830600ece806ec365a4839e79afabe183c5e36d
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-10-06_22:49:09
Locale: en-US (fi_FI)

LibreOffice 3.5.0rc3 
Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735
Comment 2 tommy27 2016-10-13 04:36:03 UTC
still present in
Build ID: e2f6c7f0d0cc14f851d7028ff846c5dc658a81c6
CPU Threads: 4; OS Version: Windows 6.29; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-10-10_23:08:02
Locale: it-IT (it_IT); Calc: group
Comment 3 QA Administrators 2018-10-10 03:05:34 UTC Comment hidden (obsolete)
Comment 4 Roman Kuznetsov 2018-10-10 07:40:02 UTC
still repro in 

Build ID: d9ad59da50c1172fe98f94370221c9c1b688200a
CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-10-08_23:34:44
Locale: ru-RU (ru_RU); Calc: threaded
Comment 5 QA Administrators 2019-10-11 02:35:05 UTC Comment hidden (obsolete)
Comment 6 NISZ LibreOffice Team 2020-11-24 17:26:55 UTC
Still bad in:

Version: (x64)
Build ID: f313e27fb7f2d42247407e26e16f264e30f87ca5
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: hu-HU (hu_HU); UI: en-US
Calc: CL
Comment 7 Justin L 2022-03-07 13:47:52 UTC
repro 7.4+
Comment 8 Justin L 2022-05-02 13:58:29 UTC
The w:dirty is irrelevant. I simply extracted the files and then re-zipped them into a new .docx and then the file opens fine. So somehow the zip compression or whatever must be corrupt.

sax/source/fastparser/fastparser.cxx-void FastSaxParserImpl::parseStream(const InputSource& rStructSource)

    // Only one text at one time
    std::unique_lock guard( maMutex );

SAL_WARN("DEBUG","parseStream source.is["<<rStructSource.aInputStream.is()<<"]");
    pushEntity(maData, rStructSource); //exception thrown here b/c !aInputStream
Comment 9 Justin L 2022-05-03 07:57:45 UTC
// FIXME64: need to read the 64bit header instead                                                                                                                                                                                     if ( nSize == 0xffffffff ||
     nOffset == 0xffffffff ||
     nCompressedSize == 0xffffffff ) {
         throw ZipException("PK64 zip file entry" );

commit 9b0198b2442bc749491d0f1e5e2c811346e5d568
Author: Michael Meeks on Fri Sep 21 13:09:29 2012 +0100
    package: convert internal ZIP handling data-types to 64bit
    Prepare for a ZIP64 implementation.
    Audit all "Size" property fetches through Anys.
    Audit all uses of nSize, nCompressedSize, nOffset through the code.
    Add FIXME64: comments to all points requiring future work.
Comment 10 Commit Notification 2023-03-08 14:55:03 UTC
Attila Szűcs committed a patch related to this issue.
It has been pushed to "master":


tdf#82984 tdf#94915 zip64 support (import + export)

It will be available in 7.6.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:

Affected users are encouraged to test the fix and report feedback.
Comment 11 Justin L 2023-04-24 20:30:03 UTC
I assume this should have been marked as fixed. I opened _Author.docx without any errors or warnings.