https://bz.apache.org/ooo/show_bug.cgi?id=126869
--- Comment #15 from orcmid <[email protected]> --- (In reply to John from comment #14) > Created attachment 85497 [details] > Broken .odt file - note garbage before the proper PK header > > See forum post > https://forum.openoffice.org/en/forum/viewtopic.php?f=7&t=83063 where a .odt > file was corrupted. > > This is the file uploaded by the poster. > > Note how the first part of the file is garbage, and the PK header appears > close to the end of the file. The .odt file opens with 7-ZIP (presumably it > ignores the garbage?) and shows the names and sizes of the internal files, > but the internal files themselves cannot be extracted. This suggests that the beginning of the file, not the end, has been lost or mangled. 7-ZIP finds the "central" directory, which is on the end, that says what all the parts are and what their offsets are to find them in the main part of the Zip. Because the file has been beheaded (or otherwise mangled), the parts can't actually be found and extracted by 7-zip (or WinZip) and a test operation will reveal that. The WinZip report is more to the point: Errors were detected -- see below for details Testing ... Error in file #1: bad Zip file offset (Error local header signature not found): disk #1 offset: 0 Error in file #2: bad Zip file offset (Error local header signature not found): disk #1 offset: 77 Error in file #3: bad Zip file offset (Error local header signature not found): disk #1 offset: 543 Error in file #4: bad Zip file offset (Error local header signature not found): disk #1 offset: 811 Error in file #5: bad Zip file offset (Error local header signature not found): disk #1 offset: 1341 testing: styles.xml OK At least one error was detected in D:\orcmid\docs\associazione\standards\OASIS\ODF\Development\Forensics\AOO-FileLoss-Corruption\Corruption-i126869-ForumUpload.odt. Note that the last component of the Zip (file #6), styles.xml, is there and checks out. (7-zip produces a stranger error report, treating blocks as if the signatures and data are there and then reporting that the data is incorrect.) I inspected the file using a hex editor. I see that the material preceding the intact styles.xml part appears to be what is left of the compressed content.xml part (File #5). There is no possible way to recover anything from this Zip. - - - - - - - - - - - By the way, we are loading too many different cases into this meta-task. It would be great to figure out how to differentiate them, use separate issues as well as we can, and link to them from this issue. I suspect that ones like this one are very difficult to replicate, but it is definitely in a class by itself. -- You are receiving this mail because: You are the assignee for the issue.
