Apache OpenOffice (AOO) Bugzilla – Issue 124636
opening xml file shows "General input/output error."
Last modified: 2017-05-20 10:35:11 UTC
I tried to open XML files with AOO 4.1 RC (not available in versions selector). Mostly¹ I get a box "General Error. General input/output error." With AOO 4.0.1 the filter dialog pop up. To simply reproduce the problem unzip any .ods file and try to open an included .xml. ¹Interesting in this context: styles.xml from an ODF is recognised as Math file.
I can not reproduce the described defect on Windows 7. In AOO 4.0.1 I get the ASCII Filter Option dialog on opening an arbitrary XML file of an arbitrary ODF spreadsheet document. The same happens in AOO 4.1.0 Beta, AOO 4.1.0 RC and AOO 4.1.0 RC2 @mroe: Which version information do you found in the About dialog? On which system did you observe the described behavior?
I've reproduced it with AOO410m14(Build:9760) - Rev. 1573601 2014-02-28 10:30 - Linux i686 AOO410m15(Build:9761) - Rev. 1583666 2014-04-01 15:58 - Linux i686 and AOO410m16(Build:9762) - Rev. 1585426 2014-04-07 10:18 - Mac OS (BTW: on MacOS the About-box shows the date twice but not the OS)
Confirmed with AOO410m14(Build:9760) - Rev. 1585624 2014-04-08_04:11:10 - Rev. 1585644 Debian
(In reply to Oliver-Rainer Wittmann from comment #1) > I can not reproduce the described defect on Windows 7. > > In AOO 4.0.1 I get the ASCII Filter Option dialog on opening an arbitrary > XML file of an arbitrary ODF spreadsheet document. > The same happens in AOO 4.1.0 Beta, AOO 4.1.0 RC and AOO 4.1.0 RC2 > Please forgot this test - my unzip of a sample ODF spreadsheet does not work. I am testing again on a new sample. > @mroe: > Which version information do you found in the About dialog? > On which system did you observe the described behavior?
Ok, here my test results on Windows 7: - AOO 3.4.1 works fine - ASCII filter options dialog pops up and XML file is loaded. - AOO 4.0.0, AOO 4.0.1, AOO 4.1.0 Beta, AOO 4.1.0 RC2 show the described defect. If I preselect the file type in the Open file dialog choosing 'Text' or 'Text Encoded' or if I rename the file from *.xml to *.txt the XML file opens as in AOO 3.4.1
Checked with a simple content.xml from a test-draw doc, it gets imported as StarMath. The StarMath detector is in starmath/source/smdetect.cxx. When breaking in SmFilterDetect::detect only starting with "<?xml" is checked, the math import is not called. Thus, the detector says yes to the file and accepts it...
AOO401 also loads as StarMath, but AOO340 does not (checking my local versions where I have some debug already). Taking a look why not...
Checked in AOO34, the FilterDetection from StarMath is not asked at all (to ensure that the Breakpoint works I created a StarMath and reloaded it). It looks more as if the order in which the filter detectors are called has changed somehow...
Interesting detail: In AOO34 the StarMath FilterDetector is *not* called when I remove the '*.odf' from the test file; in that case the StarMath importer is directly incarnated and used to test if it loads.
The following code instead of the existing in starmath/source/smdetect.cxx:329 makes the detector more careful and works (checked with a content.xml from a StarMath file), but can be polished some more: const sal_uInt16 nSize = 400; sal_Char aBuffer[nSize+1]; aBuffer[nSize] = 0; pStrm->Seek( STREAM_SEEK_TO_BEGIN ); const sal_uLong nBytesRead = pStrm->Read( aBuffer, nSize ); if(nBytesRead >= 5 && 0 == strncmp( "<?xml", aBuffer, 5) && strstr(aBuffer, "<math")) { static const sal_Char sFltrNm_2[] = MATHML_XML; static const sal_Char sTypeNm_2[] = "math_MathML_XML_Math"; aFilterName.AssignAscii( sFltrNm_2 ); aTypeName.AssignAscii( sTypeNm_2 ); }
Refined the detection a little bit to make it more safe, works as intended. content.xml's work well (not accepted), as meta.xml and others work. Also made sure that a test.xml that contains a math gets detected correctly. Interstingly, exactly that case is imported as ascii in an AOO34 which *proves* that the order of filter detection indeed has changed. That again may be a hint on the stl change using unordered lists.
Refined detection even more and checked various cases; storage files which are StarMath with and without endings, xml files which are StarMath or not with and without endings, e.g. content.xml or meta.xml from draw/writer files, all okay now with the StarMath detector denying non-StarMath files more reliable. Preparing commit for trunk...
"alg" committed SVN revision 1586271 into trunk: i124636 refine StarMath filter detector to be more specific than just checkin...
Okay, committed on trunk, done.