Issue 102081 - Very unreliable while saving documents
Summary: Very unreliable while saving documents
Status: CLOSED WONT_FIX
Alias: None
Product: Writer
Classification: Application
Component: save-export (show other issues)
Version: OOo 3.1
Hardware: PC Linux, all
: P2 Trivial (vote)
Target Milestone: ---
Assignee: writerneedsconfirm
QA Contact: issues@sw
URL:
Keywords: needmoreinfo, oooqa
: 110349 (view as issue list)
Depends on:
Blocks:
 
Reported: 2009-05-20 05:28 UTC by de_logics
Modified: 2013-02-19 01:29 UTC (History)
2 users (show)

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


Attachments
Broken file. (894.40 KB, application/vnd.oasis.opendocument.text)
2009-05-20 05:30 UTC, de_logics
no flags Details
This is the void file that I made........'accidentally'. OOo did notify about the incomplete saved operation. (10.00 KB, application/octet-stream)
2009-05-22 18:48 UTC, de_logics
no flags Details
In this very file, OOo assumed that the save operation is complete, but this was not so...as a result a void file. This can be recreated after the writer just comes out of its frozen state. (10.00 KB, application/octet-stream)
2009-05-22 18:52 UTC, de_logics
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description de_logics 2009-05-20 05:28:19 UTC
All of a sudden one fine day I tied to open a file, and on doing so it said that
it got corrupt, and offered me an options to repair, I did so, and on lightly
browsing through the file I thought it to be fine, in perfect state. So I
overwrote the file with the original file which was corrupt; only to realise
that the file which was originally 1.2 MB...or actually I think it was 2.8 MB
changed to 991 kb.

On opening the fixed document I realised that none of the OLE objects were
getting edited and some of them were shown with Object<number>.

The obvious culprit is the saving mechanism of OOo writer...which, undoubtedly
needs to be improved on both speed and reliability at least in Linux cause I've
heard this issue many time on various Linux distributions and specially with
large documents (20 pages onwards).

I'm attaching the recovered file (I don't have the original one, it was overwritten.

The file has been modified cause of confidential information in it, however I
left all of the OLE objects.

And yeah there was another calc file which got corrupt, it recovered without a
problem.
Comment 1 de_logics 2009-05-20 05:30:46 UTC
Created attachment 62385 [details]
Broken file.
Comment 2 de_logics 2009-05-20 09:06:37 UTC
Working on this file is highly unreliable, information loss persists.
Comment 3 eric.savary 2009-05-20 09:21:39 UTC
Do you have a reproducible scenario which leeds to data loss?
Comment 4 de_logics 2009-05-20 12:23:01 UTC
Yes I successfully recreated this problem.

As I thought of before (actually I knew about this and it's possible
consequences about a year ago but since it actually happened to me, I had to
report it) what the saving operation does is -

1)When you ask the software to save your work, it creates a temporary file
somewhere replicating the new and appended saved file, this is done while the
saving progress bar appears.

2)After the saving bar vanishes, the software is in a frozen state (I don't know
but gnome System Monitor 2.24.1 says its current state is
'uninterruptable')...while this happens, for a while there's no write operation
on the disk (where the file is), but after sometime, it does happen; what OOo
does at this moment is replace the existing file with the new file, for this to
happen, first the file needs to get blanked (or void), then it gets refilled
with the new data. At this moment if the disk is removed, depending on when it
is removed, there's a loss of data resulting in premature data being written on
the file. Instead of the the disk been made to remove, if there's a Kernel
failure (very likely in Windows) or a power failure or in a general a disaster,
there will be permanent data loss.

How I did it - 

I made a humongous ~40MB 3500+ page file (to ensure that the filling/replacement
process takes time).

I put it in a 4GB pen drive formatted to the worst of all FS by MS -- Fat16,
making the pen drive extremely slow. Notice that the pendrive should have a
lightsource/indication to depict the read/write operation.

I transfer this file to this pen drive, open the document, and reduce the core
frequency of the processor to its lowest possible state (again to make things slow).

Then make a small change to the end of this file (in my case, I just entered a
new line), then save the document. After this, get ready to remove the pen drive
all of a sudden...now when to remove - 

As the save progress bar appears, you will see a read/write operation (through
the indication on the pen drive) DO NOT remove the pen drive now.

When the progress bar is gone, the software will be at its frozen state and
there will be no read/write operations initially; but keep an eye on that
indicator...as soon as it show a read/write operation...remove the pen drive all
of a sudden; recreating a scenario of a system crash.

Yes openoffice does notify you about the read/write error, but that's not gonna
happen when the system crashes.

Now reopen the pendrive (do a FS check if needed), you'll see the file but it'll
be void resulting in complete data loss.

Open the file, OOo will show the character encoding dialogue.
Comment 5 de_logics 2009-05-20 12:37:28 UTC
Though this might seem impossible to happen in real life in an accident but
following the laws of probability, the probability of a crash increases with
time and in case of windows increases as the time passes without reformating the
system.

Since the file size will increase over time, the probability will still increase.

Considering multiple HD or above images in the document, the file size can
increase dramatically. Also including many formulas increases the file size rapidly.

If you have a habit of saving the files frequently, which is actually trying to
be towards the safe side; the probability of this happening will still
increase...so instead of saving files frequently being a good habit, it becomes
a bad one............all cause of this bug.


It happened to me for example!



Considering this is leading to major data loss, this bug should be the number 1
priority cause one of the main purposes of using an office suite, is the
reliability...........which in this case is worst than even gedit/kate/notepad
or various simple text editors.


I've also seen this happening in Windows vista, so I think this will be for all
OS since this is a problem with the algorithm.
Comment 6 de_logics 2009-05-20 12:56:26 UTC
Yeah...also if you've checked the 'save new version every time' box, this file
sizes can reach 100MB with ease.


The obvious solution to this will be appending the changes to the file without
moving/recreating/replacing the whole file which is not possible without
removing application of the zip compression applied here.

I think creating an uncompressed backup file at the same place as the master
document while the document is open will create a solution, appending the
changes to backup file, then compressing and then replacing the master file
without removing the backup file (which will be amended to its latest state)
thus ensuring no data loss.

This bug also account for extremely long saves which can be cut down by just
appending the backup document, which will be done in a flash. Then allowing the
user to work on the document while the backup file is being compressed to a new
zip file in the background.

This will also allow more powerful, efficient but time consuming algorithms to
be used for compression...like PAQ, which can reduce MBs into a few KBs yet
without any data loss/delay in work.


Custom compression levels can also be applied this way.
Comment 7 de_logics 2009-05-20 13:05:34 UTC
Yeah...also if you've checked the 'save new version every time' box, this file
sizes can reach 100MB with ease.


The obvious solution to this will be appending the changes to the file without
moving/recreating/replacing the whole file which is not possible without
removing application of the zip compression applied here.

I think creating an uncompressed backup file at the same place as the master
document while the document is open will create a solution, appending the
changes to backup file, then compressing and then replacing the master file
without removing the backup file (which will be amended to its latest state)
thus ensuring no data loss.

This bug also account for extremely long saves which can be cut down by just
appending the backup document, which will be done in a flash. Then allowing the
user to work on the document while the backup file is being compressed to a new
zip file in the background.

This will also allow more powerful, efficient but time consuming algorithms to
be used for compression...like PAQ, which can reduce MBs into a few KBs yet
without any data loss/delay in work.


Custom compression levels can also be applied this way.
Comment 8 de_logics 2009-05-20 13:07:47 UTC
Yeah...also if you've checked the 'save new version every time' box, this file
sizes can reach 100MB with ease.


The obvious solution to this will be appending the changes to the file without
moving/recreating/replacing the whole file which is not possible without
removing application of the zip compression applied here.

I think creating an uncompressed backup file at the same place as the master
document while the document is open will create a solution, appending the
changes to backup file, then compressing and then replacing the master file
without removing the backup file (which will be amended to its latest state)
thus ensuring no data loss.

This bug also account for extremely long saves which can be cut down by just
appending the backup document, which will be done in a flash. Then allowing the
user to work on the document while the backup file is being compressed to a new
zip file in the background.

This will also allow more powerful, efficient but time consuming algorithms to
be used for compression...like PAQ, which can reduce MBs into a few KBs yet
without any data loss/delay in work.


Custom compression levels can also be applied this way.
Comment 9 eric.savary 2009-05-20 13:42:20 UTC
Not a P1 because the scenario you describe is not a general one which affects a
majority of users but depends of a lot of conditions.

Please also try this in a current 3.1rc2 version.

@MAV: any idea about the described problem?
Comment 10 de_logics 2009-05-20 15:12:30 UTC
Ok.

I'm having problems with my download manager...so it might take some time.


Sorry about the repeated responses but the site seems very slow.


If you're not getting anything I described, I might be able to explain better.
Comment 11 mikhail.voytenko 2009-05-20 15:25:08 UTC
mav->de_logics:
First of all, if disk device becomes unavailable during writing, the office can
do nothing against file corruption. We can try to preserve the document
contents, but the file on the device will stay corrupted because the office has
no chance to repair it. From your comments it looks like you accept this base
idea, I have mentioned it only to be sure.

To prevent possible problems in this case the target document is already
backuped before it will be overwritten. The backuped version is stored in the
user backup folder ( can be found in Tools/Options/OpenOffice.org/Paths tabpage
) for the time the document is stored. After successful storing the backup is
removed, otherwise it remains there. I assume that you can still find the
backuped version of your file in this folder.

Moreover, you can let the office not to remove the backup file each time the
document is stored.

So in the scenario you have mentioned the error will be shown, and the document
stays in changed state, that means that you will be asked to store it before
closing.

If the system is crashed/turned off, the office process dies and next time the
office is started it repaires the documents that was edited before system
crash/shut down. So you are not right assuming that in this case user would get
no notification. So there is no problem at all in the reproducible scenario you
have mentioned, the data is not lost.

In case the system has crashed, the current repairing mechanics should already
be able to repair the file. If you have a concrete scenario where it does not
work please submit it. Currently we still have no concrete problem to solve, we
only know that your file was corrupted somehow. There are no known bugs in this
area, so without additional info regarding corruption scenario it is not
possible to say how could it happen.

And some more asks.
- If you have a concrete scenario regarding mentioned in your post issue
"I've heard this issue many time on various Linux distributions and specially
with large documents (20 pages onwards)."
please describe it in details, as you for example did it for the disk
disconnection scenario above.
- As well as comparing with other applications, it would be very interesting to
know what do they do better, if it is described with explicit examples, facts
and so on. Otherwise it sound just like common words that are not really based
on facts, and thus can not be taken seriously.
Comment 12 eric.savary 2009-05-20 15:35:32 UTC
@de_logics: and please try to be *concise* when describing the scenario. Thank you!
Comment 13 de_logics 2009-05-20 19:23:54 UTC
"First of all, if disk device becomes unavailable during writing, the office can
do nothing against file corruption. We can try to preserve the document
contents, but the file on the device will stay corrupted because the office has
no chance to repair it."

Yeah, but at least there wont be information loss, I mean it is recoverable.

"can be found in Tools/Options/OpenOffice.org/Paths"

Yeah I was wondering about that too, but if this technique is applied, under
circumstances of a disaster, one can trust that original file is not void, or
there is no information loss in it.

Anyway, thanks for that path...do you know the path for Linux?...cause I'm not
getting it. There are 2 tools folders in 2 openoffice folders, and consists of
some xml files...that's it.

I'll surely checkout the 40MB file there.

"So you are not right assuming that in this case user would get
no notification."

The user has the option to cancel the recovery, in this case he/she would assume
that his/her previously saved work is preserved.

"If you have a concrete scenario where it does not
work please submit it."

:-D :-D...we have ODT recovery tools costing 100 bucks for a reason.

"If you have a concrete scenario where it does not
work please submit it."

This file that I attached was "recovered"...with permanent data loss resulting
in the file size turning to half.........Anyway, I lost the main file.

I can recreate that scenario but the 40MB file that I made has confidential
information...anyway, I'll try and do it...you know I've successfully recreated
a void file which OOo doesn't even recognise as an ODT file...how can it recover?

If I'm successful in making a non void, but half-filled file, I'll surely submit.
Comment 14 de_logics 2009-05-20 19:25:55 UTC
@es

Well...I was wondering that we're all 'writers'...........making huge files.
Comment 15 eric.savary 2009-05-20 22:39:04 UTC
Then feel free to reopen when you have a reproducible scenario to submit.
Comment 16 eric.savary 2009-05-20 22:39:17 UTC
closed
Comment 17 de_logics 2009-05-21 10:08:14 UTC
Ok, I'm compressing the 87.1 MB file (now compressed to around 80MB) that I made
to upload...I could not generate the partial file, but I could generate the void
one with ease. 

Hope we don't have a limit to upload here.

Also if you remove the thumbdrive just when the software gets out of its frozen
state, though it assumes the file to have been saved, but actually we see a void
file...i.e it gives wrong information about the file.
Comment 18 de_logics 2009-05-21 10:28:16 UTC
I'm attach 2 files, one 41 MB and the other 42.5MB, they are actually
compressed, so you'll need to extract them.

I'll explain how to, you'll need peazip for that purpose.
Comment 19 de_logics 2009-05-21 10:49:37 UTC
No it will not accept files above 1 MB...I'll upload it to a file hosting site
and will post the link here.
Comment 20 de_logics 2009-05-22 18:35:25 UTC
Here are the links to the file - 

http://www.adrive.com/public/30c2fd3065a2a047b47f4083e7e8ffe1420780c58126953882e55d05f8333958.html

http://www.adrive.com/public/462fd2d9e5804040b4e1f87786d8da61ddeec255c71c561a9a1844939c4af02e.html

After downloading, you might wonder the files are useless unless this piece of
software is downloaded and installed too - 

http://peazip.sourceforge.net/

Open the first file (named Test file.tar.001.lpaq) with peazip and extract it.
For peazip's Linux version you just have to double click the tar file that
appears inside this file (which is actually an archive) and it gets extracted at
the same place as this file. I dont know for the windows version, but for the
Linux version, dont bother clicking the extract all/ extract here etc...
button...it wont work.

Do the same for the other file.

If you have a double cored processor (or above) it'll be good if you can extract
both the files simultaneously...theoretically, it should take half the time, i.e
15-20 mins on a 1.8 GHZ processor based on architecture of Athlon/Turon and
having all the catches as 512KB.

It will take 50MB memory (each).

After the tar file has been extracted, extract the 87.1 MB file from the TAR
file by extracting solely from the .001 file.

Following the procedures (as stated before) to create the error file, I've made
2 null files which I'm gonna attach...................
Comment 21 de_logics 2009-05-22 18:45:06 UTC
The file is not getting attached.


As a result I'll be attaching the 2 files as tar archives, each of them will
contain a text file named 'disposable'...with some gibberish in it. As the name
says, just dispose it.
Comment 22 de_logics 2009-05-22 18:48:10 UTC
Created attachment 62449 [details]
This is the void file that I made........'accidentally'. OOo did notify about the incomplete saved operation.
Comment 23 de_logics 2009-05-22 18:52:01 UTC
Created attachment 62450 [details]
In this very file, OOo assumed that the save operation is complete, but this was not so...as a result a void file. This can be recreated after the writer just comes out of its frozen state.
Comment 24 de_logics 2009-05-22 18:54:28 UTC
Reopening issue...............
Comment 25 de_logics 2009-05-22 19:12:18 UTC
Reproduced in OOo 3.1

Changes to version made.
Comment 26 de_logics 2009-05-25 09:24:28 UTC
The links will expire if you don't download.

If you're not getting it, pls notify.
Comment 27 eric.savary 2009-05-25 21:34:29 UTC
I did the mentioned scenario and had no problem:
- loaded file from USB stick
- made some changes in the file
- saved
- waited until progress bar disappears but OOo still usable
- unplugged at this time the USB stick
-> Error "Cannot find 'Test file.odt'"
- Re-plugged USB stick
-> OOo carried on saving.

So WORKSFORME.

Note: Tools/Options/OpenOffice.org/Paths is not a directory but directory
setting in OOo which can be found under the *menu* "Tools - Options -
OpenOffice.org - Paths". There you can see right to "Backup" where the backups
are stored on your system.

Comment 28 eric.savary 2009-05-25 21:34:41 UTC
closed
Comment 29 de_logics 2009-05-26 10:56:20 UTC
"- Re-plugged USB stick
-> OOo carried on saving."

Do NOT re-plug wile OOo process is still on...close OOo, once the stick has been
removed, then replug and check that file.

Can you explain how did I generate those void file?...they were generated using
these procedures only.


In fact you don't even need to try it out to confirm his bug, this problem is
obvious.

You used that 80 MB file, or generated your own?

reopened.
Comment 30 eric.savary 2009-05-27 08:43:15 UTC
"Do NOT re-plug wile OOo process is still on...close OOo, once the stick has
been removed, then replug and check that file."

Now I did.
When closing OOo it asks me if I want to save the document.
Thus if I save the file somewhere else (USB still unplugged) it will save
correctly. If I close and don't save, I loose changes.
Re-plugging shows a .~lock.Test file.odt# but also the Test file.odt which is
about 84 MB size and opens fine.


"Can you explain how did I generate those void file?...they were generated using
these procedures only."
No I can't. That's why we call it "WORKSFORME".


"In fact you don't even need to try it out to confirm his bug, this problem is
obvious."
Nothing is never "obvious" as long as we cannot reproduce it.

"You used that 80 MB file, or generated your own?"
I used your file.


Now considering having spent to much time faking a system crash which is not
reproducible.

An "un-qualified" comment from my side: we have backup mechanisms and file
recovery systems but when a *system* crashes, who knows really when and what
consequences it might have on the files/file system. We can fix bugs but not
"accidents".


@MAV: please leave a more qualified statement on this issue.
Comment 31 mikhail.voytenko 2009-05-27 12:31:30 UTC
I think that ES comment is completely "qualified", indeed there is no known
problem with the recovery mechanics in the scenarios where office can do the
reparation. I just want to continue the discussion for the case that there is
one that we did not recognize.

"Yeah I was wondering about that too, but if this technique is applied, under
circumstances of a disaster, one can trust that original file is not void, or
there is no information loss in it."

Are you joking? The target disk is no more available during file overwriting,
and you expect that the file being overwritten is still OK?

""So you are not right assuming that in this case user would get no notification."
The user has the option to cancel the recovery, in this case he/she would assume
that his/her previously saved work is preserved."

Why should the user assume it? He has tried to store and got an error, why
should he throw his document away?

"This file that I attached was "recovered"...with permanent data loss resulting
in the file size turning to half.........Anyway, I lost the main file."

What do you mean by "recovered"? There are two kinds of recovery:
- the office/system has crashed, the edited document are recovered if possible
after office restart
- the office opens already broken document, the office shows warning and tries
to repair the document ( as much as possible )

I know, it is a pity to loose important changes, but the question is how exactly
has it happened, did you cancel storing of the document, or was it a system
crash that did not allow correct recovery? Please concentrate on the scenarios
you could reproduce yourself while answering, no hypothetical speculations.
Comment 32 de_logics 2009-05-27 16:28:28 UTC
@es

"Thus if I save the file somewhere else"

I know it will do that, but in a real crash, you wont get that option

"No I can't. That's why we call it "WORKSFORME"."

Ok...lets see how openoffice works, tell me...it does recreate the whole file
right...I mean, it empties the file and then again fills it...right?

"No I can't. That's why we call it "WORKSFORME"."

I'm a physics guy...actually a theoretical physics guy. i.e its my job to
predict changes with some known information. So I'm into these things.

Here, in this case the data in the file first gets deleted and then again gets
refilled, while the refilling process is on, and I remove the flashdrive,
concluding that there is there is no data loss is sheer stupidity. You don't
even need to practicals to do that. In fact in programing, there is no barrier
between theory and practicality...its the same thing.

Practically trying to recreate this is like practically checking a folder for
data without any copy-paste operation in it...now is that not obvious?

However, I did recreate the problem...you just need to have swift hands and slow
the computer down. If you're in vista, there should be an option to set the
power state of the processor (in %...which is actually not true cause there are
usually 3 or 4 power states; but cause its MS, such crap was expected), set it
to 0%...for both maximum and minimum.

Also pls do not use a pendrive with a data transfer rate of
like.......30MBps...the point of using a pendrive is defeated that way. If
you're on vista...do not format it in NTFS...only in Fat32 (since you have no
option for fat16...like with me).

"we have backup mechanisms and file
recovery systems"

Now where is it (I'm not talking about autosaves)?...can someone give me the
path for Linux?...and pls don't tell me its the tmp folder.

@mav

"Are you joking? The target disk is no more available during file overwriting,
and you expect that the file being overwritten is still OK?"

Yeah THAT is the main issue...instead of overwriting the file, it can just be
amended, that way there will be absolutely NO data lost for the previously
stored data and the save process will finish in a flash rather than waiting for
half a minute.

"Why should the user assume it? He has tried to store and got an error, why
should he throw his document away?"

If you plug your system from the mains you won't get any errors right? I've
already explained that this will be *simulating* a disaster...no one will plug
the pendrive off all of a sudden while a read/write operation is on...that means
I'm doing it for experimental purposes...and it has succeeded.

Ok...suppose I kill the OOo thread even after the partial save process (i.e
after I unplugged the pen drive) and with OOo notifying me about it...thus
making a an actual disaster sinario.

I restart any of OOo component, and it shows me the recovery option...I click
next...it says the file is corrupt, then repairs it and opens a blank document
which is....I guess around 7kb...i.e reduced from 87 MB to 7 KB...or an empty file.

"What do you mean by "recovered"?"

I don't know exactly what happened, but by recovery I mean it showed an option
to recover the file, and I clicked a yes. So this is the recovered file...you
cant edit even one OLE. The second case as per your definition.

As said before, I did produce those void file...should I make a video on how I
did it? We do have such software in the repos though...should be easy.
Comment 33 eric.savary 2009-06-02 23:57:54 UTC
As I said before: an accident is an accident. It does not mean bug. You can
reproduce a system crash in a "laboratory" (plugging off the file system at time
x+34, file system which has to be formatted like this and not like that and
considering a processor running at X and not Y). Ok! Fine!

Now: how often in real life do all those parameters meet together to let us think:
a) there is a problem we may address ENHANCING our save process
b) we have a real bug?

I mean: If I hit my hard drive with a hammer there are 3 theoretical cases:
a) nothing happens: the drive has not been damaged
b) the drive has been partly damaged: some parts of the disc are destroyed but
the disc works for the rest
c) I destroyed essential components: the drive is completely useless

This issue is: you have experienced c) and because you are a clever guy you
could reproduce it from scratch because:
- you found out the exact impact point for the hammer
- the velocity needed to damage the drive at that point
- the angle the hammer should hit the drive with that velocity at that point...
and so on...

It remains that an accident (system crash, hammer on drive) happened and that we
cannot invest time tracking every possible physical damage and take preventive
measures against them.

Considering this issue as a theoretical interesting but practical not worth of
tracking scenario.

Closing as WONTFIX though WORKSFORME could also apply.
Comment 34 eric.savary 2009-06-02 23:58:14 UTC
closed
Comment 35 de_logics 2009-06-03 18:22:39 UTC
This is NOT a lab environment, I'm simulating a real system crash..that's all.

Point is OOo saving mechanism NEEDS to be changed we got 2 solid reasons - 

1) Its extremely unreliable.
2) No one wants to wait for a minute or 2 to save a 'space' that was made
towards the end of a document.

Its unreliability is worst than gedit...a simple text editor..........is this
what you expect from an office suite?

I mean this office suit has a tag "When saving with OOo, you CAN loose data,
which you will not if using MS office or even a simple text editor...with the
same accident"

Ok...this happening might be rare, but if it does happen, to guy to which it has
happened will lose lots of labour....I mean that file...which contained like 100
mb of text + formula + images etc.... will be reduced to 0 bytes...you realise
how much hate will that guy towards the office suite and the community?

And this is VERY probable when the file size increases and if the system/file
system speed reduces (which is again VERY probable in an net book with its
processor at the lowest power state).

I'm not asking you to chop your system to pieces, I'm just asking you to plug
the power off.......and the data's lost. I did not even do anything physical.


Actually there is NO office suit except this one which actually WIPES all
previous data in such a case..........to be explicit, this is the MOST
unreliable office suit at its current state.



Cause of this very saving mechanism, making an book in openoffice is
IMPOSSIBLE...the file size reaches 1 MB, saving the file frequently becomes a
pain, you actually have to think before pressing ctrl+s......which you don't
have to with MS office no matter what the file size is.



By closing the issue, you mean to say that OOo will destroy all your data in
case of a system crash/power failure...which will not damage any other file in
the same partition (i.e except that openoffice document)...or there even won't
be any loss of data in the other file. Its cause of Openoffice that you will
loose data on the partition...nothing else is to blame.

Reopening + changing priority to P2
Comment 36 eric.savary 2009-06-03 19:09:01 UTC
One more time...

We cannot reproduce what you describe (once again: I unplugged the USB stick at
the moment you described, got an error, closed OOo and didn't shred the file on
the USB stick -> only the changes are lost) and which seems only to be
reproducible in VERY RARE circumstances.

Now we have new statements from your side...

"No one wants to wait for a minute or 2 to save a 'space' that was made
towards the end of a document.
"

1) But it's a fact when the file is 80 Mb big.
2) Now you're talking about performance -> an other problem. Please file an
issue asking for the "Quick save" à la Word but have a look before if there is
no duplicate about that.


"I mean this office suit has a tag "When saving with OOo, you CAN loose data,
which you will not if using MS office or even a simple text editor...with the
same accident"
"

Now we are in the area of the block affirmations without proves and metrics,
like the headline of a tabloid: "OOo CAN lead to data loss!!! MS-Word or an
editor never!!!"

Did you make the same tests with both?
An editor is an editor. Plain text, no layout, no pkg stream... Please don't
compare with a Word processor.

"Actually there is NO office suit except this one which actually WIPES all
previous data in such a case..........to be explicit, this is the MOST
unreliable office suit at its current state.
"

Same as above... You made a detailed benchmark of all the suites on the market I
guess?

"Cause of this very saving mechanism, making an book in openoffice is
IMPOSSIBLE..."

<sarcasm>Since years, hundred of thousands of people indeed NEVER achieved
this!</sarcasm>

"which is again VERY probable in an net book with its
processor at the lowest power state"

Is this a theoretical assumption or ARE YOU REALLY experiencing those problems
on a net book????
AFAIK a net book (as the name says) is NOT made for word processing and
certainly not for 80 Mb files...



@MAV: do you have any comment on this?
Comment 37 de_logics 2009-06-05 19:04:49 UTC
"We cannot reproduce what you describe"

Ok...I'll make a video.

"but have a look before if there is
no duplicate about that."

I always do, but it never works out.

"An editor is an editor. Plain text, no layout, no pkg stream... Please don't
compare with a Word processor."

So you agree that a text editor is no comparison to a word processor.

BUT it's reliability's worst than that!!!...that's what I mean...its reliability
is SOO bad!

"Is this a theoretical assumption or ARE YOU REALLY experiencing those problems
on a net book????"

I'm REALLY experiencing this...why don't you see the void files, I made it that way.

Wait, I'll make a video.
Comment 38 de_logics 2009-06-05 19:06:46 UTC
No its not a netbook.

It's processor is 1.8ghz dual core (AMD).
Comment 39 de_logics 2009-06-06 09:14:05 UTC
I've successfully made a ~70 MB file which opens to be 'blank'...after the
fixing operation (it got made while I was making the video).

Should I attach it?

Also you cannot extract that corrupt odt file cause........its corrupt.

Once (video made) OOo said the save operation was complete but it did not save
the changes (though the file was intact, i.e not corrupt), this is different
from last time when the saved file was void and OOo still said the save
operation was complete.
Comment 40 de_logics 2009-06-06 17:47:42 UTC
I've uploaded the videos.

First download this file - 

http://www.adrive.com/public/c521e27bc8c7a0ec5cc12bd6be3ab2092e6d1048f2f6c74c20e9ee81480366fe.html

Then - 

http://www.adrive.com/public/6c33cc1174e8eb239b6cf6a4c182e23ab1a4456708d5df72505f8b9f645a96c7.html

Both of them are lpaq8 archives...extract them the usual way.

Now you should get a tar file (not 001) when extracting the second one...extact
thsi extracted tar file...then you should get the 002 and 003 files.

Place the .001, .002, .003 files at one place and extract the tar from the .001
file (i.e its the header)

You will get 2 videos...play them with smplayer (I really don't know about the
format).
Comment 41 de_logics 2009-06-08 11:53:37 UTC
The  links will expire...
Comment 42 eric.savary 2009-06-08 13:17:45 UTC
Not reproducible on Windows.
If you use Ubuntu, check this again in a native (not Ubuntu but from our site)
OOo build.

We don't use incremental saving so that, yes, when overwriting the file with the
new version, if a system crash happens at this moment, the file may be  corrupted.

To be on the safe side, use:
"Tools - Options - Load/Save - General - Always create backup copy"

The rest is WONTFIX.
Comment 43 eric.savary 2009-06-08 13:18:04 UTC
Closed
Comment 44 de_logics 2009-06-08 18:30:42 UTC
Considering the saving mechanism is same for MS windows, the problems should
obviously persist.

Changing the platform wont change the saving algorithm.

You need to have a swift-gamers hand.

Tell me when exactly are you removing the pendrive? Or it can happen that that
save status bar does not work the same for ubuntu and windows.

Yeah I downloaded and installed from OOo site...that's why it required java.

The OOo in the Debian repos is till 2.4

"We don't use incremental saving so that, yes, when overwriting the file with the
new version, if a system crash happens at this moment, the file may be  corrupted."

That's EXACTLY what I've been trying to say since ages!

Yeah, I was searching for that option after that incident...thanks.
Comment 45 Rob Weir 2013-02-19 01:29:39 UTC
*** Issue 110349 has been marked as a duplicate of this issue. ***