Bug 154587 - FILEOPEN Calc doesn't open XLSX archive
Summary: FILEOPEN Calc doesn't open XLSX archive
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.2.0.4 release
Hardware: All Windows (All)
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: target:24.8.0 target:24.2.1
Keywords: filter:xlsx
Depends on:
Blocks: XLSX File-Opening
  Show dependency treegraph
 
Reported: 2023-04-03 14:42 UTC by Xisco Faulí
Modified: 2024-02-02 14:51 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Xisco Faulí 2023-04-03 14:42:20 UTC
This issue is a follow-up of bug 124525 and it only happens on Windows.
I found this issue when I created a unittest for bug 124525: See https://gerrit.libreoffice.org/c/core/+/149956

Steps to reproduce it:
1. Open attachment 150508 [details] from bug 124525 on Windows

-> The file is corrupted and it can't be loaded

Reproduced in

Version: 7.5.1.2 (X86_64) / LibreOffice Community
Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129
CPU threads: 1; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded
Comment 1 Xisco Faulí 2023-04-03 14:50:15 UTC
Hi Noel,
Since you fixed bug 124525 I thought you might be interested in this issue which is only happening on Windows
Comment 2 m_a_riosv 2023-04-03 23:49:33 UTC
Reproducible, it opens in excel.
Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: c4a58634753a84b09f20f7271d6525a6656522d3
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded Jumbo
Comment 3 Noel Grandin 2023-04-12 14:06:44 UTC
Where did you get this file from?

unzip says that has very dodgy entries, it seems to only work by accident on Linux. 

I am honestly tempted to rather add some error checking to make sure this fails on all platforms.
Comment 4 Gabor Kelemen (allotropia) 2023-05-22 00:58:46 UTC
(In reply to Noel Grandin from comment #3)
> Where did you get this file from?
> 
> unzip says that has very dodgy entries, it seems to only work by accident on
> Linux. 
> 
> I am honestly tempted to rather add some error checking to make sure this
> fails on all platforms.

The File - Properties dialog says it was created & modified by "SMExport suite" and that seems to be this thing: 

http://www.scalabium.com/sme/
"The native Delphi components in this suite provide fast and direct data export into MS Excel, XML, HTML, SPSS, PDF and other formats from a DBGrid, Dataset or any VCL control!"
Comment 5 csyu.279 2023-05-24 20:27:31 UTC
I was unable to reproduce in:

Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 45826e60d5f1508d54b0f0a4d98b0e2ebe94a097
CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

And the system completely crashed in:

Version: 4.2.0.0.alpha1+
Build ID: fc8f44e82de4ebdd50ac5fbb9207cd1a59a927e3

I was able to open the document in Google Spreadsheets while using my WindowsOS
Comment 6 Xisco Faulí 2024-02-01 10:29:25 UTC
Still reproducible in

Version: 24.2.0.2 (X86_64) / LibreOffice Community
Build ID: b1fd3a6f0759c6f806568e15c957f97194bbec8f
CPU threads: 1; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded
Comment 7 Xisco Faulí 2024-02-01 10:30:11 UTC
Hi Mike, since you fixed some RepairPackage issues recently I thought you might be interested in this issue
Comment 8 Mike Kaganski 2024-02-01 12:37:47 UTC
unzip -Z "D:\Downloads\1554162786671199 - Copy.xlsx"
Archive:  D:/Downloads/1554162786671199 - Copy.xlsx
Zip file size: 8002 bytes, number of entries: 18
drwx---     2.0 fat        0 b- defN 19-Apr-01 16:39 _rels
-rw----     2.0 fat      588 b- defN 19-Apr-01 16:39 _rels/.rels
drwx---     2.0 fat        0 b- defN 19-Apr-01 16:39 docProps
-rw----     2.0 fat      877 b- defN 19-Apr-01 16:39 docProps/app.xml
-rw----     2.0 fat      625 b- defN 19-Apr-01 16:39 docProps/core.xml
drwx---     2.0 fat        0 b- defN 19-Apr-01 16:39 xl
drwx---     2.0 fat        0 b- defN 19-Apr-01 16:39 xl/_rels
-rw----     2.0 fat      980 b- defN 19-Apr-01 16:39 xl/_rels/workbook.xml.rels
drwx---     2.0 fat        0 b- defN 19-Apr-01 16:39 xl/theme
-rw----     2.0 fat     7046 b- defN 19-Apr-01 16:39 xl/theme/theme1.xml
drwx---     2.0 fat        0 b- defN 19-Apr-01 16:39 xl/worksheets
-rw----     2.0 fat      439 b- defN 19-Apr-01 16:39 xl/worksheets/sheet2.xml
-rw----     2.0 fat      439 b- defN 19-Apr-01 16:39 xl/worksheets/sheet3.xml
-rw----     2.0 fat      624 b- defN 19-Apr-01 16:39 xl/workbook.xml
-rw----     2.0 fat     1490 b- defN 19-Apr-01 16:39 [Content_Types].xml
-rw----     2.0 fat    19903 b- defN 19-Apr-01 16:39 xl/worksheets/sheet1.xml
-rw----     2.0 fat     1197 b- defN 19-Apr-01 16:39 xl/sharedStrings.xml
-rw----     2.0 fat     1722 b- defN 19-Apr-01 16:39 xl/styles.xml
18 files, 35930 bytes uncompressed, 6068 bytes compressed:  83.1%

The "d" directory entries confuse our ZIP implementation. I have an easy fix for this, and with it, it opens fine when opened normally; but even with this fix, the recovery mode (with RepairPackage MediaDescriptor property) fails.

I am really confused, why does it work on Linux? (Even in recovery mode.) The code that fails on Windows doesn't look system-specific... Needs debugging. Possibly that would suggest a way to fix it better.
Comment 9 Mike Kaganski 2024-02-01 13:25:53 UTC
(In reply to Mike Kaganski from comment #8)
> I am really confused, why does it work on Linux? (Even in recovery mode.)
> The code that fails on Windows doesn't look system-specific... Needs
> debugging. Possibly that would suggest a way to fix it better.

Ah, pity; this works only because unordered_map sorts entries in the opposite order in Linux case; so "_rels" comes after "_rels/.rels".

I have another idea how to treat the recovery case, though.
Comment 10 Mike Kaganski 2024-02-01 16:19:23 UTC
https://gerrit.libreoffice.org/c/core/+/162888
Comment 11 Commit Notification 2024-02-01 20:08:26 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/747463809e50c132557a95dcee6709a1fa82d760

tdf#154587: allow directory entries in ZIP packages

It will be available in 24.8.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:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 12 Commit Notification 2024-02-02 11:50:57 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-24-2":

https://git.libreoffice.org/core/commit/d6c47949fc57d0fd115dc0f2f99ad8da89eab8bc

tdf#154587: allow directory entries in ZIP packages

It will be available in 24.2.1.

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:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 13 Commit Notification 2024-02-02 14:51:23 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1ffe39721049d55f9b63e942d27878b4ae7b49e0

tdf#154587: sc_subsequent_filters_test4: Add unittest

It will be available in 24.8.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:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.