Created attachment 81128 [details] The test file The file attached is viewed fine in Microsoft word viewer but when open in libre office I get a message "general input/output" error.
Hi, I have been testing this file and confirm that I get the message 'General input/output". The processor is running at 100% and opening the file take more than 2 minutes to reach the error message. However, when pressing retry the file is opening.
On low speed processor (netbook) it can took 2 times to press to retry to get result. Note that formatting of the table looks strange
*** This bug has been marked as a duplicate of bug 67699 ***
It's not a duplicate of bug 67699, as the latter is a regression of 4.1, while this bug was reported against 4.0. Also bug 67699 is fixed as of 4.1.2.2, while this bug still reproducible. Tested with Fedora 19 (64-bit) in VirtualBox + lowered Execution Cap (to emulate slow processor). However it opens fine on my host machine (LO 4.1.1.2 under Ubuntu 13.04 64-bit).
(In reply to comment #4) You are absolutely right. Still reproducible under Ubuntu. I should have been more careful.
*** Bug 70537 has been marked as a duplicate of this bug. ***
Caused by http://cgit.freedesktop.org/libreoffice/filters/commit/?id=2e9f9d82110342601d28408ae77d63b673993ebe. There is always 60 seconds timeout before the error message is displayed. So if the document is not so large and the processor is not so slow, then it opens without any error. For more information, see Bug 35543.
*** Bug 61546 has been marked as a duplicate of this bug. ***
Reproduce with Version: 4.3.1.0.0+ Build ID: 5536b127a105123de6f64dcf8f53dfa277faef3c TinderBox: Win-x86@42, Branch:libreoffice-4-3, Time: 2014-07-16_10:15:31 Windows XP SP3. Set platform to all.
I first noticed this bug behaviour when I was trying to open a 100M MS 2003 XML spreadsheet. MSO 2013 opens that file within 5 seconds, but LibreOffice takes forever to load it while using 100% CPU, then finally gives I/O error message. I was thinking LO failed to load it because of its file size. But after I made the file size much smaller (50M->10M-5M...), LibreOffice still fails to open it (high CPU, error message). Files with only a few KB size can open with no problem
*** Bug 82264 has been marked as a duplicate of this bug. ***
Hi all, I have the exact problem. LO Calc 4.3.0.4 I thouught, the problem is the XML format, but it's the size. Strange thing is, that this bug says, it!s been fixed long time ago... http://www.libreoffice.org/bugzilla/show_bug.cgi?id=44969
Another strange thing is, that Calc can save such file just fine. I have just tried to create large 10Mb spread sheet, save it as XML file, which works fine. Then when you try to open it, it crashes....
Just to clarify: This "General I/O error" message is not a bug but a feature - see bug 35543 comment 20. It will appear every 60 seconds *anyway*, a user just need to click "Retry" to continue the import process. The real bug here is the wrong text of that message.
OK, I get the point, but in that case, why it takes 5 minutes to open 10Mb file? (5x times click retry) Should I write bug on that?
(In reply to comment #15) > OK, I get the point, but in that case, why it takes 5 minutes to open 10Mb > file? (5x times click retry) XSLT processing is slow, it's not related to LO. Try it yourself from the terminal: $ xsltproc --output output.fods /opt/libreoffice4.3/share/xslt/import/spreadsheetml/spreadsheetml2ooo.xsl input.xml > Should I write bug on that? No.
OK, I get the point again. So the solution is not to use XML, but other format. Thanks for clearing that out.
(In reply to Comment # 16 <https://bugs.freedesktop.org/show_bug.cgi?id=65980#c16>) > XSLT processing is slow, it's not related to LO. Try it yourself from the > terminal: Yes, XSLT processing might be slow. I'm not sure that is a sufficient answer. Excel manages to open such files in a fraction of a second where LibreOffice takes minutes. You might argue that these files are not very common and therefore it's not worth fixing this, but from a user's point of view, it just seems excessively slow. I agree that fixing the message will be an improvement, because at the moment there's no indication that clicking on retry is something that is likely to help.
(In reply to comment #18) > Yes, XSLT processing might be slow. I'm not sure that is a sufficient > answer. This is a sufficient answer, because we don't have a real filter for those types, just this horrible XSLT stuff. There is nothing better currently. > You might argue that these files are not very common and therefore it's not > worth fixing this I didn't say that (and BTW such files are more common than you might think). The point here is that there is no way to "fix" this like any other bug, instead someone needs to create a whole new filter for those types (which is not a trivial task). And just like any other feature request we have, someone needs to be interested enough to work on this. Anyway this discussion is out of scope for this particular bug, because the error message in question is not specific to one particular format.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.