Issue 69993 - Saving .ods write error
Summary: Saving .ods write error
Alias: None
Product: Calc
Classification: Application
Component: save-export (show other issues)
Version: OOo 2.0.2
Hardware: All All
: P3 Trivial with 16 votes (vote)
Target Milestone: ---
Assignee: mikhail.voytenko
QA Contact:
Keywords: needmoreinfo, oooqa
: 82054 (view as issue list)
Depends on:
Reported: 2006-09-29 22:58 UTC by kpritchard
Modified: 2017-05-20 09:57 UTC (History)
20 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

error dialog (137.62 KB, image/bmp)
2007-01-24 01:37 UTC, johnnyb01
no flags Details
File that demonstrates the problem (saved in Microsoft because I couldn't save it in ODS format. (2.14 KB, application/vnd.oasis.opendocument.spreadsheet)
2009-12-10 00:21 UTC, risner
no flags Details
part 1 / 5 (1000.00 KB, text/plain)
2010-01-14 16:56 UTC, birioukoff
no flags Details
part 2 / 5 (1000.00 KB, text/plain)
2010-01-14 16:57 UTC, birioukoff
no flags Details
part 3 / 5 (1000.00 KB, text/plain)
2010-01-14 16:58 UTC, birioukoff
no flags Details
part 4 / 5 (1000.00 KB, text/plain)
2010-01-14 16:59 UTC, birioukoff
no flags Details
part 5 / 5 (950.88 KB, text/plain)
2010-01-14 17:00 UTC, birioukoff
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description kpritchard 2006-09-29 22:58:25 UTC
After running Calc for several days (maintaining a spreadsheet) I attempt to
save my .ods file and I get an error, "Error saving the document file.ods; Write
Error. The file could not be written".  I get this error if I attempt to save as
a .sxc too, but not if I choose .xls.  I can close and re-open Calc and re-save
the .xls as .ods, but until I restart OO, it won't save and loses data.
Comment 1 delorea 2006-10-09 12:10:26 UTC
you are using OOo 2.0.2
Did you tryed some later version? (2.0.3)

Note that 2.0.4 is in the last fase before releasing (maybe next week).
Can you post the wole file you are not able to save, and steps to reproduce the

Comment 2 delorea 2006-12-15 09:31:21 UTC
Any news?
Comment 3 delorea 2006-12-20 10:33:07 UTC
As decided with Kara I will wait until 15 Jan 2007 to see if the problem is
present also in new official release before to close as invalid.

Comment 4 harlan879 2007-01-03 16:38:53 UTC
I have essentially the same problem, also on an x86_64 Linux system, where a
large spreadsheet (about a dozen pages, each with 10,000 cells or so) that has
been saved many times in the past will not save, with the same error. I'm
running OOo 2.1. I can export to XLS then re-import into ODS, and fortunately no
critical formatting or whatever is lost. 
Comment 5 delorea 2007-01-15 13:23:05 UTC
Hi harlan
can you provide steps to reproduce the issue?
And can you provide a sample file?

Comment 6 harlan879 2007-01-16 17:56:25 UTC
Ambrogio, unfortunately I can't easily replicate this. The same spreadsheets
work fine and save fine 98% of the time. I've had the problem with several
different spreadsheets. All of them have on the order of 10 sheets, with most
sheets having 10,000 or so cells, most of which are (fairly simple) formulas.
There are typically a few charts on each page, mostly scatter graphs or line
graphs. If I can consistently replicate the problem with a particular file, I'll
certainly do so, but I suspect some very funky interaction with a memory leak or
other subtle internal problem that doesn't lead to replicability...
Comment 7 johnnyb01 2007-01-24 01:36:40 UTC
I guess this is a Core issue. Issue 67317 reports the same thing for Writer
(closed/worksforme), and I am experiencing the same problem in Impress (Win2k,
OOo 2.1.0). Only I have the additional problem that I can't save in .ppt format,
either... OOo hangs. I've only experienced it once, on a file that I've used and
saved many times.
Comment 8 johnnyb01 2007-01-24 01:37:58 UTC
Created attachment 42419 [details]
error dialog
Comment 9 frank 2007-02-16 12:51:37 UTC
Hi Pavel,

could you have a look at this one please ? I'm not able to reproduce it but do
not have a 64 bit build available.

Comment 10 pavel 2007-02-24 15:28:45 UTC
kpritchard: can you please provide exact way to reproduce this issue?

If you can't I have to mark this as WORKSFORME, because I can save into .ods.
Comment 11 harlan879 2007-02-24 18:04:48 UTC
Pjanik, please do not mark this "worksforme". Several people have reported the
same problem, but it is clearly a very subtle bug with interacting causes.
Instead, please leave the bug open (and the needmoreinfo keyword is very
appropriate) until someone (who knows, maybe me!) can replicate it consistently.
Thank you.
Comment 12 pavel 2007-02-24 18:22:02 UTC
kpritchard: so please provide the detailed description how to reproduce this.
Comment 13 kpritchard 2007-02-25 23:04:35 UTC
The problem I had was not one that could easily be reproduced.  I have been
doing a lot of work lately, so I have not had my system (or OpenOffice) left
running for the length of time I had before.  I'm also now using OO 2.0.4
under FC6.  The basics are:

long, multi-sheet spreadsheet, when open for 1+ weeks (used nearly daily), at
random times would decide to not save as .ods, only .xls.  If I could find a
pattern that would guarantee the behavior, I'd be happy to share it with you.
It sounds like some others who've posted to this thread have had more
frequent issues with the problem.

I have not had the problem since my last upgrade, however, my use pattern has
changed, since I've had to regularly shut down and restart completely for
other projects.  I'll attempt to duplicate and will let you know if I can
keep the long-project going long enough to say with confidence the problem
was resolved for me.

Comment 14 kpritchard 2007-03-05 00:34:53 UTC
It finally happened to me again.  This time on a simple spreadsheet I use to
make monthly schedules.  kcalc had been running since 2/20.  The file it occured
on was last saved on 2/2 and had been processed via a "recovery". on 2/20.  I do
still wonder if it has something to do with the recovered files.  I've had other
file problems with that service.
Comment 15 j2006 2007-03-09 23:31:13 UTC
I experience the same problem with Mac OS X. In fact is a constant annoyance
since the Mac only sleeps (normally I do not shutdown) and OpenOffice is usually
open with a sheet keeping track of things. The sheet changes always since I load
some external data. The problem started for me with the OOo 2.x versions (latest
version used is 2.0.4 X11). The OOo 1.x versions I used did not have the problem
and saving always to xls seems the only way to avoid it.

The only thing that seems (not completely sure) to prevent the problem with .ods
documents is always save after every change or never leave a document open for
more than a few hours (or less than a day?) whitout saving. 

My impression is that this problem occurs always when the ods document stays
open without saving for a certain time (like a day or more). 
Comment 16 j2006 2007-05-12 14:30:42 UTC
Can this be in the "Save AutoRecovery information" option? 
Switching off that "feature" seems to help. I have opened different copies of
the same .ods spreadsheet in OOo X11 (whithout "autosave" enabled) and NeoOffice
(with autosave enabled) around a week ago. Applying the same changes, updating
the same links and only saving after a few days worked in both.

It seems similar behaviour was fixed with patch 15 for NeoOffice:
Comment 17 j2006 2007-05-23 22:35:24 UTC
I can now confirm that switching off the "autosave" does not help. After leaving
open a spreadsheet for more than 6 days without saving (changing some things on
the first few days and not touching it for 6 days) the "write error" is given again.

I will stop using OOo X11 now, so I can not provide any further input on this
bug (on the Mac I will use NeoOffice and on Solaris StarOffice 7, both no longer
| not affected by this bug. On both I keep different sheets open for days/weeks
which makes OOo 2.x unusable for me with the .ods file format).
Comment 18 j2006 2007-06-17 12:55:46 UTC
It appears that NeoOffice 2.1 on Intel Mac with patch 5 applied also is
affected. After installing the Patch on 1 june saving an open sheet with the
.ods format failed on 12 june.
So I guess this is something in the 2.x code base that affects
all the software using the code.
Comment 19 j2006 2007-10-31 22:51:26 UTC
If somebody with more programming skills than me is going to look at this, maybe
the following experience is helpful: 

Since I forgot to save and close an ODF-document I got this bug again. I noticed
the following:
- "lsof *" in the directory with open files only showed the .xls files open, not
the .ods that could not be saved.
- "ls -lc <filename>.ods" showed a change in access time after every
unsuccessful attempt to save that file. 

I tried to open another ods file to see if that would stay open in the lsof
output but the program crashed. After restarting the program all opened files
where shown by lsof. 

Remark: I think it is clear that this bug is not restricted to Linux on Opteron.
I guess "platform" and "OS" might need to be changed to "All" (or at least all
platforms and all unix like operating systems?).

Comment 20 pagalmes.lists 2007-12-07 11:00:29 UTC
Had the same problem on Windows on OOo 2.3.

The document was opened from a server. Left it several days and had the same
Comment 21 jbf.faure 2008-01-19 20:27:18 UTC
Add me to CC
Comment 22 mind_booster_noori 2008-04-03 16:41:24 UTC
This issue still happens in 2.3.0, and someone found out how to get around it.
Please read since
that info is - it seems - important heling the resolution of this bug.
Comment 23 mind_booster_noori 2008-04-03 16:42:20 UTC
*** Issue 69993 has been confirmed by votes. ***
Comment 24 flonatel 2008-04-23 09:12:47 UTC
I was able to reproduce this: for me it occurs, when the /tmp directory is full:
1) Start openoffice (for me the problem occurs also with impress and writer)
2) Open some document
3) do a 'dd if=/dev/zero of=/tmp/oooo' in a shell (will stop, when /tmp is full)
4) Try to save the document
5) Error dialog pops up (same as in attachment)
(Do not forget to 'rm /tmp/oooo' afterwards :-)
Comment 25 j2006 2008-05-20 21:28:11 UTC
I noticed interesting behaviour with OOo 3.0 Beta (Mac OS X Intel, Aqua) today:

- the .ods file was not seen as open by lsof when I tried to save and had this error
- after a while the same file was seen by lsof again
- the file could be saved without a problem when trying it again 

Default save format configured as ODF 1.2 (all of the above is with OOo 2.x
based software and ODF 1.0 file format I guess?, use "unzip -p document.ods
meta.xml" and look at the office:version= value)

No relation to temp space or paging as far as I know, but this /tmp scenario
sounds to me like something that might cause the same error message on a default
configured (open)Solaris and/or Linux system?

Can it be like this: Using spreadsheets with all software based on
- OOo 1.x with ODF 1.0 is not affected (1.0 called .sxc)
- OOo 2.x with ODF 1.0 has this bug (1.0 / 1.1 files called .ods)
- OOo 3.x with ODF 1.2 not sure yet, maybe the behaviour is different?

Anyway, maybe it is of some interest to know how OOo 3.0 behaves with different
file formats like with ODF 1.0 spreadsheets .. I'm not volunteering by the way I
was just curious to compare OOo 3.0 to NeoOffice and tried it with ODF 1.2 just
once. I have given up on OOo with ODF. I'm using .xls since that is the only
stable and reliable format to use with the OOo 2+ based software (as far as I know).
I think I have seen some poll on Slashdot about using OOo with ODF? Might that
explain why this bug is still "new" after two years? Nobody uses ODF it seems.

Comment 26 birioukoff 2008-10-27 15:01:08 UTC
The same problem first appeared to me on OOo 3.0 final and this caused me
downgrade back to 2.4.1, but it also regularily happens. We're working in a
workgroup of 4 people in a big project, an any of us meets the same problem
(WinXP & Linux Mint 5), but there's still no reliable way to repoduce this bug.
We are trying hard to find it out. 
Comment 27 ehedstrom 2009-01-12 06:18:40 UTC
Got this error today from OpenOffice 3.0.0 on a Mac (Intel, OS X 10.5.6), using
OO Draw.

OOo had been open for a couple of weeks in the background. Trying to Save or
Save As... the document as an .odg or .sxd gave me the error. Saving as xhtml or
StarDraw 5.0 .sda worked ok. Even after saving as an .sda document, saving to
OpenOffice formats gave this error until I restarted OpenOffice.
Comment 28 birioukoff 2009-01-26 05:17:25 UTC
After a while of testing with different files during workflow I've got a stable
(in my case - please test it and report) workaround of this annoying bug.

In almost all cases the problem was in autofilters. I've noticed that on at
least 1 sheet there is a strange-behaving autofilter that does not disappear
when you put filter on some other sheet. And only when you manually turn on and
off filter on that strange region, the file saves without errors. 

Xls format supports multiple non-named-database-region-connected autofilters,
but OOo itself - not, it supports multiple data-region-coonected filters (as
region's property). I don't know if ODF 1.0/1.1/1.2 support multiple
autofilters, but saving code for xls supports it, and for ods - not. Maybe this
is a way to look for?

P.S. Can it be intresting if I attach the ods file with this error?
Comment 29 j2006 2009-04-06 21:16:35 UTC
2 observations:

- a colleague claims never to have any problems when saving a spreadsheet that
remains open for a long time. The maybe important difference is that his
workstation is always running (with Linux).
- Just now I observed an error about an attached USB drive when waking up my
computer, therefore it makes sense I could not save the open spreadsheet. It
makes less sense that I could not overwrite it. Usually there are no "errors" or
"disconnects" on waking up the computer. Maybe the sleep/wake-up (on OS X) is
one possible cause for this issue? 

BTW, I don't know any other applications that seem to have a problem with open
files on some (external) storage as long as devices with mounted file systems
are not disconnected during sleep. My problems are usually on the internal
drive, so that remains connected all the time.
Comment 30 brotherjason 2009-05-06 12:18:18 UTC
I just had this with OpenOffice 3.0.0 and 3.0.1 on a machine running Windows XP

The issue occured when I tried to save a .xml File. I've been working with the
very same .xml file for several days and never had any problems with it. I have
tried the following to work around the problem:

1. Tried to save the .xml File with another name as .xml -> Fail.
2. Copied the .xml File prior to opening it somewhere else and then tried to
save it as .xml with the same name -> Fail.
3. Opened the another .xml file and tried to save it as .xml -> Fail.
4. Opened the .xml File saved it as .ods, Then opened the .ods File and tried to
save it as .xml -> Fail on last step.
5. Uninstalled OpenOffice 3.0.0 and reinstalled as version 3.0.1, then tried to
save the .xml after opening it with OpenOffice 3.0.1 -> Failed on last step.
6. Rebooted the computer and retried all of the above workaround attempts -> all

Error Message in all cases :"Error saving the document. Write Error."

Prior to the first time the bug occured I had the same .xml file opened with
UltraEdit 14.00b, but had the program closed before opening the .xml File using
OpenOffice 3.0.0. At the time the issue occured the file was located on a server
(meaning I accessed it via LAN). However from attempt #2 onwards the retesting
was done with local files only.

maybe this intel helps reproducing the issue.
Comment 31 brotherjason 2009-05-07 10:29:13 UTC
Just tested the issue again today and the very same files that didn't work
yesterday allowed to be saved now.

I have found that OpenOffice generates a lock file for the opened files, which
is discarded once the file was closed. However when the issue occured yesterday
this file was not created in the process of loading the file, which leads me to
believe it may have something to do with the issue.
Comment 32 arthurgoldberg 2009-05-18 15:23:43 UTC
I experience a similar problem.
Running Neooffice 3.0 patch 2 on OS X (uname -a) 9.6.0 Darwin Kernel Version
9.6.0: Mon Nov 24 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386 

Neooffice says "Error sving the document xyz: Error writing the file"
Preferences - NeoOffice Paths says Temporary files =

ls -l of this says:
-rw-------@ 1 arthurgoldberg  staff  48629 May 13 14:21 sv11n.tmp
-rw-------@ 1 arthurgoldberg  staff      0 May 13 18:15 sv14e.tmp
-rw-------@ 1 arthurgoldberg  staff      0 May 13 09:58 svl7.tmp
-rw-------@ 1 arthurgoldberg  staff  84931 May 11 10:45 svo5j.tmp

lemme know if you want more info
Comment 33 arthurgoldberg 2009-07-03 16:02:33 UTC
I leave NeoOffice (and most other programs, for that matter) open indefinitely.
The "Error saving the document <file>.ods; Write Error. The file could not be
written" is reliably reproducible. 

I'm happy to provide debugging info to anyone working on it.

Comment 34 birioukoff 2009-07-03 16:21:12 UTC
Thank you Arthur!
Could you provide a reliable way to reproduce the bug?
Because I have this bug quite often, but still haven't a reliable way.
All I have noticed is that it may be connected to autofilters.
Comment 35 kuppelhuber 2009-08-03 14:28:49 UTC
I have exactly the same issue. I use Windows XP and OOo 3.0.1 and 3.1.

I have some spreadsheets which have worked for a long time and now i can open
the file but when i try to save the file i get the message "Error saving the
document documentation: Write Error. The file could not be written."

I can save the file as .xls but not as .ods or .ots. The original file is saved
as .ods.

So i must say that is a bug with a high priority because i can`t open all of
these files and save as .xls or copy and paste it into a new spreadsheet.

So can you tell me why the problem exists since 2006 and there is no fix for it?

With best regards 
Comment 36 ooo 2009-08-06 13:09:25 UTC
Apparently this issue is a collection of different findings on several platforms
and for different release that accumulated over years.

@mav: with the findings from 'kuppelhuber' this affects the current release. The
issue was sticking at the reporter 'kpritchard' to provide more information,
what he did, and needs to be reassigned for development.
Comment 37 ooo 2009-08-06 13:16:14 UTC
Additional findings, citing 'kuppelhuber' from IRC:

"i have a new fact...when i open the file close the file and leave the calc open
and then reopen the file than it works...then i can save the i think
it must be a lock on the file"
Comment 38 ooo 2009-08-06 13:21:43 UTC
*** Issue 82054 has been marked as a duplicate of this issue. ***
Comment 39 kuppelhuber 2009-08-18 13:36:23 UTC
Now i have checked what lockfiles are created when i open the file. First it
creates the lockfile for the program under "documents and settings\user
name\application data\\3 and then it creates the lockfile for the
opened file in the directory where the file is stored. 

When i close the file and leave the program open then it only deletes the
lockfile of the opened file and the lockfile of the program is still there. 

So i have tried some scenarios:

1. copy the lockfile of the program, reopen the program and insert the copied
lockfile and tried to save => same error

2. copy the lockfile of the opened file, reopen the file and insert the copied
lockfile and tried to save => same error

So what is the difference between only open the file in OOo and open the file in
OOo, close the file and leave the program open and reopen the file?

Please tell me. I don`t have any ideas now.

With best regards
Comment 40 mikhail.voytenko 2009-08-18 14:32:27 UTC
I see currently the following possibilities for the problem:
- The temporary folder is full, so the office is no more able to create
temporary files. That might affect big documents, although it still might be
possible to store the small documents, it depends from the amount of free place
in the temporary folder.
- The temporary files were removed while the document was open. That happens on
Mac regularly, since the OS there removes non-locked temporary files there. But
some users have the same problem on Windows if they install tools that clean the
temporary folder.

Currently I do not see another possibility to have such problem, that of course
does not mean that there is no such possibility.

mav->kuppelhuber: If it is so easy to reproduce with the document you have,
could you please attach the document.
Comment 41 kuppelhuber 2009-08-19 14:26:49 UTC
I have to disappoint you because this is not the cause of my problem.

The problem appears not only on my pc but also on other computers with OOo.

The OOo version is also different but the same problem occurs.

Regrettably, i am unable to send you the file because it is from human resources
department, sorry.

With best regards
Comment 42 risner 2009-11-22 17:14:30 UTC
I have had this problem as long as I have used Openoffice on a Mac.  I used
NeoOffice from 1.1.2 to NeoOffice 3, then to evade this error I switched to
OpenOffice Aqua and currently run OpenOffice native 3.1.1.

I will state facts:
1) I use Openoffice for character sheets for gaming, work, and more.
2) I never close documents, I leave them open for weeks/months/years (never make
it years.)
3) I never run out of disk space (laptop has 500 gb with 200+ gb free.)
4) I never save on a network share, local disk only.
5) I noticed the "temporary directory" in options is gone
(/var/tmp/hu/huQhsjhf... and still fails if you alter the temp directory to be
/var/tmp for instance.)
6) You can save in any document format other than ods or odt such as xls.
7) You can not save the document as the same name, as a different name, or on a
different file system (such as a flash disk or external disk.)
8) You must have left the file open between weekly games and it rarely fails in
1 week but often fails after 2 weeks.
9) It does not depend on the file, as every document fails and all of them were
created organically from scratch (no comment sheets and no comment document; in
other words all documents that fail started as "create new document".)
10) I have found no work around for this problem in 5 years and all the work
arounds I've seen for similar problems point to locking, disk full, and other
11) Toggling "Save Autorecovery information" and "Use openoffice open/save
dialogs" after the problem presents does not allow saving.
12) I never use macros and never have macros enabled, but I always have complex
sheets with hundreds, possibly thousands of cells referencing other cells.

Theorized assertions:
1) I suspect all files have at some point in their life have been through a
recovery cycle due to laptop crash.
2) When the problem presents with one document, not all open documents will
present the problem (in other words, I have notice that sometimes only 1 or 2
documents will fail while others that have failed in the past successfully save.)

This is the sure fire way to reproduce:
Open a new document.
Past in a lot of text in different cells in different sheets over several weeks.
Craft cells that reference other cells that reference many other cells.
Modify several cells over several hours, then leave the document open for a week.
Repeat the last line without saving until you decide/remember to save.

Sometimes you are gifted with the power to save, often you are not.

If you are unconvinced and want a copy of an offending file, I can provide one.
 But since every single openoffice document I've ever used in my life has
exhibited the problem I strongly believe it isn't a document issue.  I have been
taught to save often and frequently to work around the problem, but I am human
and sometimes forget to save.

Even simple files with say 12 columns and 20,000 rows of data each referring the
cells on the same row has exhibited the problem.

I'm posting this information in 88318 also.
Comment 43 risner 2009-12-10 00:21:02 UTC
Created attachment 66577 [details]
File that demonstrates the problem (saved in Microsoft because I couldn't save it in ODS format.
Comment 44 risner 2009-12-10 00:26:40 UTC
Since this has been ignored (and is so easy to reproduce), I decided to create a
new calc document, change the name of the first sheet, and leave the file alone
for a couple weeks.

I can no longer save the document.  So I saved it as an xml file and attached it
to this problem.

There is no work around for this other than creating a new document and hand
copying all the sheets from the old document to the new document then hand copy
all the settings (page size etc) to duplicate the document.  So this is a
massive inconvenience.
Comment 45 birioukoff 2009-12-10 09:40:10 UTC
2 risner: I can't reproduce the problem with the file you have attached. I open
it and save it as in a regular way without any problems. We still do not have a
100% guaranteed way reproduce it :( I strongly believe that it is connected with
autofilters, not the period of being opened.
Comment 46 risner 2009-12-10 16:04:33 UTC

I can't reproduce the problem with the file you have attached. I open
it and save it as in a regular way without any problems.  I strongly believe
that it is connected with autofilters, not the period of being opened.

I don't think I explained myself correctly.  I didn't have a problem with that
file (which had but one change from a "blank" file) either for over a week of
"being open."

So if you could open it and save as ODS, the only thing I can say is so can I. 
That isn't the test.  Leave it open in an unused window for 3 weeks, then try to
save it.

As for the second thing, how do I test the "autofilters" problem you suggest? 
How do I confirm that?  Since I now have several "persistent" unsaveable files
on my computer I am maintaining for testing purposes.  I can do any
troubleshooting you need.  Would you like a system call trace of the save action?
Comment 47 mikhail.voytenko 2009-12-10 16:12:45 UTC
Adjusting the target, if there are enough resources the problem should be
investigated for OOo3.3 release. OOo3.2 contains now additional logging
functionality that should allow user to provide more feedback in case of
problems during storing of document. Hopefully it will allow to to detect what
goes wrong here.
Comment 48 arthurgoldberg 2009-12-10 18:03:01 UTC
My experience is the same as "Additional comments from risner Sun Nov 22
17:14:30", although I run NeoOffice 3.0 and don't have time to file a detailed
Debugging this problem depends on 
1. tracing the stack that produces the "The file could not be written" error  
2. determining other operations on the document's temporary and primary files 

File it as a serious bug.
Comment 49 birioukoff 2010-01-14 16:56:32 UTC
Created attachment 67193 [details]
part 1 / 5
Comment 50 birioukoff 2010-01-14 16:57:24 UTC
Created attachment 67194 [details]
part 2 / 5
Comment 51 birioukoff 2010-01-14 16:58:25 UTC
Created attachment 67195 [details]
part 3 / 5
Comment 52 birioukoff 2010-01-14 16:59:21 UTC
Created attachment 67196 [details]
part 4 / 5
Comment 53 birioukoff 2010-01-14 17:00:31 UTC
Created attachment 67197 [details]
part 5 / 5
Comment 54 birioukoff 2010-01-14 17:13:36 UTC
I have attached a sample file that certainly gives this error. It was tested on
several machines & OS's. See attachment 'error_issue_69993.7z.001-005'. File was
split due to size limitations. 

Actions that cause the error:

1. Open file.
2. Press "Delete" button on cell Tests.A10 (or change content of any other cell).
3. Press "Save" button.
4. Enjoy.

IMHO from this moment this bug should be considered as reproducable.
Comment 55 birioukoff 2010-01-14 17:26:02 UTC
What to do to workaround the issue:

1. Put autofilter on sheet "2".
2. Put autofilter on sheet "5".
3. Put autofilter on sheet "14".
4. Press "Save".

After all above file saves OK. But later error returns and you have to play with
autofilters again to be able to save changes made.
Comment 56 risner 2010-01-16 03:59:24 UTC
Just to be clear, if this autofilters related:
1) I had never heard of autofilters prior to this bug report.
2) After looking at what autofilters are, I'm sure I never intentionally added 
these to my documents.
3) I've been able to reproduce this problem with an idle new document with only 
the sheet name changed (so nothing in any cells and a single change from 
"create new document")

So this means that if it is autofilters related, then autofilters periodically 
enable themselves, and periodicially prevent (seeming at ramdom) a document 
from being saved.  Or this problem is unrelated to autofilters and there is an 
autofilter related problem that produces similar faults.
Comment 57 kyoshida 2010-01-16 17:22:17 UTC
Please be aware of Issue 108374, which fixes a very infrequent memory corruption
issue during export of any XML-based file format, which basically covers all of
.od* and .sx* files as well.  The memory corruption occurs in the sax writer
code, so all applications are affected.

I haven't verified that this issue and Issue 108374 have the same root cause,
but they possibly could.
Comment 58 gdiebel 2010-06-11 14:49:24 UTC
birioukoff, I tested your document and indeed it did fail to save each time.
Changing the autofilter settings did not in my case allow the document to save.
After testing various settings I have found something which allows the document
to save. In your Tools/Options/General -- Open/Save Dialogs -- check the box for
Use dialogs. Now try saving your example again.
Comment 59 mikhail.voytenko 2010-08-05 13:20:28 UTC
Changing the target to 3.4. Please set it back if you believe that this issue
should be handled as a showstopper for OOo 3.3.
Comment 60 mind_booster_noori 2010-08-16 09:46:13 UTC
It is important to have this on OOo 3.3. 
Comment 61 eracc 2010-08-16 16:11:59 UTC
I concur that this is an important bug that needs to be fixed in 3.3 at the
least. The target milestone should not be moved further back, sooner would be
Comment 62 Martin Hollmichel 2011-03-15 12:50:44 UTC
set target to 3.x since not release relevant for 3.4.
Comment 63 Ash 2011-08-06 12:39:14 UTC
As I've Written on Issue 118369.
Since there is no reply to the stated issue, I will re-post the same
comment as below.

I am using 3.3.0(Japanese Version) running on Vista.
When I save a calc file with range name defined, I get a "Write Error".

Here's how to replicate the error;
1. Create a new calc file and define data range name
   [Data]->[Define Range]
2. Input some name using "Hankaku" letters
   (which is basically the direct input mode, so if you are using
    English version, any letters would do)
3. Save doc and restart PC.
4. Open the above file before any other OOo file and try to save it.
5. Write error occurs.

So far I've found that the below conditions must be met
in order to replicate this error.

1. File must contain database name that includes "Hankaku" letters
   (Or just say, alphabets & numbers by direct input mode)
2. It must be the first file to be opened and saved.

And here are the work arounds (any of the below should avoid the error);
1. Rename data range by using "Zenkaku" letters.
   (Which is Japanese input mode)
2. [Menu]->[Reload] before save.
3. Open other Calc file before opening the error producing file.

However, if "Quick Launch" is turned off, the error occurs almost every time.

At first, I thought that this was something to do with language pack,
since the error can be avoided using "Zenkaku" letters.
However, I was able to find similar issues that are probably related to
this one from countries where there is no "Hankaku" or "Zenkaku" input mode.

This could be a problem when importing an Excel file that contains Autofilters.
Because the filters are automatically named as "Excel_BuiltIn~" upon import.
And the above error occurs more likely.

Please have a look. I hope my descriptions help a bit.
Thank you in advance.
Comment 64 Ash 2011-08-06 12:42:23 UTC

[Menu]->[Reload] is wrong.
[File]->[Reload] is correct.
Comment 65 j2006 2012-11-10 12:57:34 UTC
Does this bug still exist in OpenOffice 3.4? It seems gone from LibreOffice 3.5 and 3.6 versions.
Comment 66 HD 2012-11-19 08:11:34 UTC


Both downloaded from the official site, followed steps described at
Comment 63 and used sample file from Bug 120170 to reproduce.
It seems that this bug does not occur with English version.

Also, not reproducible with LibreOffice 3.4.0 and later versions.
But there is no official announcement about bug fix for this so it is
possible that they might have changed something which somehow fixed
this "Write Error" bug too as a by-product.
Comment 67 Rainer Bielefeld 2013-11-11 05:43:10 UTC
Currently the only thing we know here is that the bug does exist and might be related to OOo. But no way to get it reproducible, no step by step instruction, ...

Comment 68 Ash 2013-11-20 16:23:19 UTC
Hi Rainer.

Just a quick confirmation, but have you disabled the quickstarter before performing the test? Meaning, disabling this feature via Tools Menu and then restarted your PC?

More precise steps are;
1. Launch AOO and go to Tools -> Options.
2. Go to version is still 3.4.1 so this may have been changed to Apache OpenOffice.) -> Memory -> Disable the Quickstarter.
3. Restart PC and wait until startup is complete.
4. Kill all soffice.bin just to make sure, and then open the sample file from bug 120170.
5. Edit and save.

Apologies if you have already followed the steps exactly as instructed.
I will find the time to download the newest version and test it again on my end.

Thank you for your time.
Comment 69 Ash 2013-11-25 18:59:03 UTC
The bug persists after a fresh installation of
Downloaded from the official page below.

Running on Windows 7 Home Premium SP1 64-bit
Intel(R) Core(TM) i5-3450S CPU 2.80GHz
RAM 8.00GB
Comment 70 Edwin Sharp 2014-01-17 12:48:13 UTC
Can not reproduce comment 68.

AOO410m1(Build:9750)  -  Rev. 1558424
Win 7
Comment 71 myAOObugz 2014-05-20 22:20:03 UTC
(In reply to birioukoff from comment #55)
> What to do to workaround the issue:
> 1. Put autofilter on sheet "2".
> 2. Put autofilter on sheet "5".
> 3. Put autofilter on sheet "14".
> 4. Press "Save".
> After all above file saves OK. But later error returns and you have to play
> with
> autofilters again to be able to save changes made.

This^^^ exactly!

I kept experiencing seemingly random inability to save an .ods, and finally noticed a pattern... it was when I'd turned on autofilter for a bit. After that, could never save.

After finding this instruction above, I tested, by also enabling autofilter on sheet 5 (sheet 2 was the sheet I already was using autofilter, and with only 6 sheets in this book, there is no reason to go higher).

It worked!

With just the three sheet numbers that birioukoff provides, I notice a pattern if it helps in determining cause. Starting from "1", multiply by 3 and subtract 1 in order to arrive at the next sheet number.

I'd do more testing, but I just pasted a fairly simply IF/Match into about 30,000 cells and will apparently need to wait a year or so before control returns to the user. :(

EDIT before posting: Control did finally return, and I was able to resume testing. Further iterations revealed that whilst enabling autofilter on another sheet would allow saving w/o error, it is not following the 2-5-14 pattern referenced above. 

I did just make it mad somehow by enabling autofilter on just sheet 4, and this save operation (what was taking ~5seconds) may yet take all night -- this, on an SSD?

OpenOffice 4.1.0
AOO410m18(Build:9764)  -  Rev. 1589052
2014-04-22 11:43:54 (Di, 22 Apr 2014)
Win7pro SP1 64bit 16GB
Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz