LibreOffice says: Error saving the document ... Write error The file could not be written.
Has been fixed in LibreOffice 3.3.2
Created attachment 45913 [details] a file that can be edited but not changed
I am getting this in 3.4.1 with my data.
Works fine for me (Linux, LO 3.4.3).
Created attachment 53371 [details] It cannot be saved as Excel 2003 XML. It still fails for me. I attached an example.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
This persists in 3.5.0beta2.
(In reply to comment #5) > Created attachment 53371 [details] > It cannot be saved as Excel 2003 XML. > > It still fails for me. I attached an example. It works fine for me with 3.4
LO 3.5.0rc3 on WinXP SP3 32bit I open the file 452.50 KB, type some new info and try to save as "Microsoft Excel 2003 XML (.xml)". After 45 seconds Calc says: "Error saving the document ...: Write Error. The file could not be written."
I too am experiencing this bug. And probably the related long read times of 2003 XML, hang and sometimes crash of XML 2003 spreadsheet. It never crashes on load of an EXCEL generated spreadsheet. It can save the Excel generated spreadsheet once. But exit OO or LO and then re-load OO or LO calc and try to read the oo written file: a) sometimes, hangs and crashes b) sometimes, does not. But when does not, can't write the file XML 2003. Get the long wait then file IO write error, as previously described. Can write the file as ODT, and other formats. Seems the 2003 XML file by some seems out-dated or obsolete. Why we need it: 1) it is simple to parse using XML tools. If a very 'flat' low maintenance spreadsheet format. So the data in the file is accessible easily be simple easy to write tools. 2) is the only format that meets the crieria a), and is common with MS EXCEL. 3) the new formats, are quite a bit more work to parse, write tools to read the data in the files. Is there any progress being made on this issue. It seems to have been a problem since after OO 2.2, I think I saw a report of these bugs as far back as 2008. And a long line of disgruntled attempts to use it, and of course the format will fall in disuse if it dont work. Please, is there a patched filter we can use?
Both bugs found and verified. For got to mention. Is on 3.3 Linux OO. Is on LO 3.5 Win 64. +G
Reported bug on 3.5 beta, also on release
Still here in 4.0.2.2 under Linux x86
I try to summarize, seems that 2 issues here: 1. attachment 45913 [details] from soshial -> XML file can't be changed & saved 2. attachment 53371 [details] from Scott -> XLS file can't be saved to Excel 2003 XML Don't know should it be splitted to 2 bugs? Confirm that 2 issues occured while I'm testing with LO 4.0.3.3 (Win7 32bit) Set Version to: 3.4.1 -> oldest release based on comment 3 Set Platform to: All -> known problems on Windos & Linux 32 & 64bit
(In reply to comment #14) > I try to summarize, seems that 2 issues here: > 1. attachment 45913 [details] from soshial -> XML file can't be changed & > saved > 2. attachment 53371 [details] from Scott -> XLS file can't be saved to Excel > 2003 XML > > Don't know should it be splitted to 2 bugs? To be honest this bug appears to have become a mess. If LO is started from the terminal the messages output there give a clearer indication of which attachment exhibits which problem. The first attachment does not appear to exhibit a problem under Ubuntu 10.04 x86_64 running: - v3.3.0.4 OOO330m19 Build: 6 - v3.4.6.2 OOO340m1 Build: 602 - v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b - v3.6.7.2 Build ID: e183d5b - v4.0.6.2 Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24 - v4.1.3.2 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a ... at least in terms of opening, modifying the contents (e.g., typing "a" into A1), and re-saving to the Excel 2003 XML format. v4.0.6.2 does take a long time to re-load the saved document. v4.1.3.2 throws a "General input/output error" on re-load after save. This is likely a separate issue. Unfortunately though this problem of not saving changes was initially reported against v3.3.0 release and gradually increased over time by several people (possibly for several different issues), so if this attachment does have a problem it may be Windows-specific and relate to a quite early version. I would set the Platform back to Windows and Version back to 3.3.0 accordingly. The remarks in comment #11 and comment #13 need to clearly indicate which attachment is being used. The second attachment exhibits the problem described in bug 52035 i.e., infinite template recursion.
Created attachment 90798 [details] soshial's file saved under Linux using v3304 through v4132.
A mess indeed but reproducible for me on OSX 10.9 LO Version: 4.3.0.0.alpha0+ Build ID: b578d23d3131f30d775e07baa6fa26e247ea999d TinderBox: MacOSX-x86@49-TDF, Branch:master, Time: 2013-12-13_00:32:50 * open the file "it cannot be saved as excel 2003 xml" * enter some content * save as * 2003 XML LO crashes: http://pastebin.com/qjzkFAU3 So all OS seems correct.
(In reply to comment #17) > A mess indeed but reproducible for me on OSX 10.9 LO Version: 4.3.0.0.alpha0+ > Build ID: b578d23d3131f30d775e07baa6fa26e247ea999d > ... > LO crashes: http://pastebin.com/qjzkFAU3 Well it is certainly /a/ problem, although the original reports did not indicate v3.3 thru v3.5.0rc3 crashing. Trying to determine if it is the same issue will be a challenge. Disconcerting to see a more serious problem in the alpha releases, even for a marginally used format.
hehe, yes I never understood what XML is used for in the area of spreadsheets but that maybe due to my ignorance or little knowledge in that area. Never used that myself or saw any use. Owen, could you escalate this to the dev chan?
(In reply to comment #15) > v4.1.3.2 throws a "General input/output error" on re-load after save. > This is likely a separate issue. Small update on this. Re-tested attachment 45913 [details] under GNU/Linux using: v4.1.6.2 Build ID: 40ff705089295be5be0aae9b15123f687c05b0a v4.2.6.3 Build ID: 3fd416d4c6db7d3204c17ce57a1d70f6e531ee21 v4.3.2.2 Build ID: edfb5295ba211bd31ad47d0bad0118690f76407d v4.4.0.0.alpha0+ Build ID: df73f4115cfe4d07e4159adf087571687eb173ec TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-09-25_23:06:16 v4.1 appears to have suffered a regression in handling the OPC 2003 XML file format, as the version listed eventually becomes unresponsive. v4.2-4.4 all handle opening, updating, saving, closing, and re-opening the updated file as expected. > The second attachment exhibits the problem described in bug 52035 i.e., > infinite template recursion. (In reply to comment #17) > * open the file "it cannot be saved as excel 2003 xml" > * enter some content > * save as > * 2003 XML > > LO crashes: http://pastebin.com/qjzkFAU3 I have just realised that this is the attachment I mentioned above as being covered under bug 52035. The example in this report may be XLS->XML and in the corresponding report ODS->XML but it is the XSLT filter that seems at fault. foss, if you can confirm you get the same error for the attachment in that bug, I think we can RESOLVE this one as WORKSFORME. Thanks.
Per last comment attachment from soshial works already from LO 4.2, and Scott's is another issue, probably already reported as bug 52035.