Opening Excel XLS spreadsheet which contains XML fails with "General Error. General input/output error."

English
, , ,
#1

Hi,
I’m trying to open an Excel XLS spreadsheet containing XML code with LibreOffice version:

Version: 7.1.5.2 (x64) / LibreOffice Community
Build ID: 85f04e9f809797b8199d13c421bd8a2b025d52b5
CPU threads: 2; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: it-IT (it_IT); UI: it-IT
Calc: threaded

But get the same “General Error. General input/output error.” both on Windows 10 and Ubuntu Linux 20.04 (I also tried with LibreOffice 7.0.6, with the same results), while no error or warnig is given using MS Excel.

The example XLS example.xls contains XML code and is the output of Microsoft Reporting Services, on which I have no control.

I already tried to open it using “Microsoft Excel 2003 XML” file type, as suggested in other threads (es. link, but to no avail.

Is there a different file type or different strategy I should try?
Thank you for your support!

#19

Copying from that bug’s comment:

The document is broken.
It contains

<Cell ss:StyleID="s24"><Data ss:Type="String">Identificatore</Data>NamedCell ss:Name="_FilterDatabase"/&gt;</Cell>

at (1-based) position 2504, which instead probably (unchecked) should be

<Cell ss:StyleID="s24"><Data ss:Type="String">Identificatore</Data><NamedCell ss:Name="_FilterDatabase"/></Cell>

File a bug at your Microsoft Reporting Services.

Update:

The real brokenness in that document seems to be yet something different, citing from that bug’s comment 8:

The <x:WorksheetOptions> element is nested in the <Workbook> element instead of the <Worksheet> element, i.e. there’s a closing </Worksheet> before.

#20

I did that… or better, I did file a bug at the service, which uses Microsoft Reporting Services, providing that kind of file as output.
Since my company uses that service, I have not the option to choose a different provider nor to file directly a request to Microsoft. They have responded correcting the xml output… But the file has the same apparent problem, which I have no tool to identify.

#2

The sample file provided by you caused an error with LibreOffice 7.1.4.2. However, Apache OpenOffice 4.2.0 (for clarity: an ancient development build) opened it without errors, both when I explicitly selected Excel XML 2003 for the open filter and when I merely dragged and dropped the file to the program window.

Well, use AOO.

P.S. It looks to me like a good reason for a bug report.

#3

Hi,
I’ll open a bug report if the consensus is that it’s something that should work as is. Unfortunately, installing AOO is not an option, for company policy reasons I can do nothing about… but thanks for the suggestion.

#4

Which consensus do you need? You have a situation when LibreOffice fails opening a file in a format that is said to be supported. It is enough for a report per se. Besides, you have at least one confirmation of the problem (by me) and a report that another program sharing essentially the same code base opens the file fine.

#5

Opens in LibreOffice

Version: 5.4.7.2
Build ID: c838ef25c16710f8838b1faec480ebba495259d0
CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: kde4; 
Locale: en-US (en_US.UTF-8); Calc: group

hence a (regression) bug.

#6

Thank you, you are right, of course… and thanks for checking with other versions of LibreOffice and Apache Open Office.

#7

If older LibreOffice versions or AOO accept this broken document it doesn’t mean it’s good.

#8

However, it means that the import filter might be improved to compensate for minor glitches in such files, which will ensure better compatibility with Microsoft products.

#9

It is unexpected and erroneous content in an XML element. You’d like to silently ignore that? If MS-Excel didn’t ignore it then maybe that Microsoft Reporting Services would had been fixed.

#10

What would be actually useful is to replace the meaningless “General input/output error” with something descriptive, e.g. “The file contents is broken and can’t be imported”. Even in that form, without giving exact details (providing which would be even better), it would already be more user-friendly.

#11

If MS-Excel didn’t ignore it

You miss the point. Excel does not ignore it (in fact, AOO does), it compensates for missing markup items. Of course, it is bad practice, but it makes its users happy.

#12

No, the point is not that there’s a way to workaround others’ bugs (which Excel obviously does). The problem is that doing that, (1) it’s unspecified which way of compensating is “correct”, and (2) the errors get unfixed in the source, becoming a kind of secondary standard. It’s a way to rendering all standards invalid and creating a mess.

Additionally, the situation was not that Excel “compensates for missing markup items”, as you imply, which would mean that Excel devs become aware of something and took effort for handling that. In fact, they simply did not handle some situation in code, making the program behave in unspecified manner, and saving their time and resources by not coding it right. Then “Reporting Services” devs saved their time and effort by not generating correct documents, not reading documentation, not checking the results.

#13

And now you suggest that LibreOffice devs pay for those commercial devs not doing their job, by trying to design a way to workaround, debugging it all, to provide bug-compatibility and behave in the reverse-engineered way. Nice. :confused:

I have double-checked. No, Excel does not try to “compensate”, it just ignores the out-of-context text.

#14

I understand the point, but as a user, it would be very useful to have at least an idea of what is wrong with the file. Probably it isn’t a LibreOffice’s bug… I’m considering a feature request (log somewhere some detailed informations that could help in discerning the error), but I’ll have first to search if it has already been filed by someone else.

#15

@ByteWanderer: you made a perfect bug report, and as I see, even reopened it (absolutely correctly), because it turns out it’s not the invalid structure that caused this. What we discussed here turned out to not be relevant for your case: we discussed how to handle invalid input that is only accepted by another program because of their bug.

For your case, I think it just needs to be fixed (and by the way, I was going to add a comment there stating that we should ignore the valid XML, even if it’s invalid Excel XML, because we always ignore unknown elements in external formats, assuming that there might be some unknown extension, when I saw your comments there in the bug).

#16

Following the advice of the community, I have submitted bug 143600.

Edit: This is the second xls that the company provided example2.xls… The problem apparently is the same (I have no tool to discern).

#17

And it’s still broken… citing from that bug’s comment 8:

The <x:WorksheetOptions> element is nested in the <Workbook> element instead of the <Worksheet> element, i.e. there’s a closing </Worksheet> before.

Again, file a bug with your Microsoft Reporting Services provider.

#18

Btw, how does that company want to compensate me for wasting my time on debugging this?

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.