Bug 144360 - Asked to repair ods file(which is really an xlsx), choosing no opens anyway (as valid xlsx), but choosing yes fails to open (as invalid ods)
Summary: Asked to repair ods file(which is really an xlsx), choosing no opens anyway (...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: All All
: medium trivial
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, regression
Depends on:
Blocks: FormatDetection
  Show dependency tree / graph
 
Reported: 2021-09-07 16:17 UTC by elias estatistics
Modified: 2023-05-29 08:57 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Attachments
corrupted(???) ods file (55.44 KB, application/vnd.oasis.opendocument.spreadsheet)
2021-09-07 16:17 UTC, elias estatistics 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description elias estatistics 2021-09-07 16:17:38 UTC 
Created attachment 174863 [details]
corrupted(???) ods file

Asking repairing ods file, choosing no, says not open but open

1) Click ods file
2) prompt to repair file  "Should LibreOfficeDev repair the file?"
3A) Answer no "The file 'Auto_CODING.ods' could not be repaired and therefore cannot be opened."
4) File open normally

3B) Answer Yes - "The file '$(ARG1)' could not be repaired and therefore cannot be opened."  4) file not open 


(see attachmenet)

ps. Experimental feautures on for 4k+ columns
Comment 1 Mike Kaganski 2021-09-07 16:57:54 UTC 
Repro using master, and also Version: 7.2.1.1 (x64) / LibreOffice Community
Build ID: 3cfc32d9754d2d239bd8ce2941029c12873010c1
CPU threads: 12; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: en-US
Calc: threaded Jumbo.

The attachment is *not* an ODS, but an XLSX (with wrong ODS extension). Renaming it to XLSX "fixes" the problem.

However, this is still a bug: I suspect that the error message is generated at format detection stage, which should not happen. If rejected, the failing ODS filter is rejected, detection proceeds, and other filters are tested normally, selecting the correct XLSX filter eventually. Accepting the fix terminates the detection, and expectedly fails to open the file using wrong filter.

(again, this is just a guess.)

Interesting to check if this works in an earlier version.
Comment 2 Mike Kaganski 2021-09-07 17:05:57 UTC 
OK with Version: 4.2.0.4
Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71

Bug in Version: 4.3.0.4
Build ID: 62ad5818884a2fc2e5780dd45466868d41009ec0

Regression.
Comment 3 Mike Kaganski 2021-09-08 05:40:17 UTC 
https://gerrit.libreoffice.org/c/core/+/121766 is a code that I created this night; it doesn't work as intended, and I abandon it, and put here just as a possible pointer to whoever wants to try to fix this and solve the problem that is mentioned there in the message of the change.
Comment 5 Justin L 2021-12-09 08:35:36 UTC 
Moving to trivial. I can see attempting to solve this if the fix is also trivial, but as Mike already notes, it doesn't seem to be entirely straightforward.
Comment 6 Mike Kaganski 2021-12-09 14:55:47 UTC 
(In reply to raal from comment #4)

The two (or maybe three) commits from the list are important here:

https://git.libreoffice.org/core/+/f82f7bf3dd5053049259f6933d1335f6c9e314dd
https://git.libreoffice.org/core/+/dddd9b41f59fa9857159cef70add9e2343dd1ab1
https://git.libreoffice.org/core/+/4b7bdef4b1d1e4ff45a8816c038df38ce7995b3d (?)

Thanks raal!

Unfortunately, this won't help much here: the change is architectural, and the regression is the side effect of the chosen architecture, not some small mistake. Still, knowing these changes allows one to have a look at the change, and see the logic implemented there - which might help designing a fix.