Apache OpenOffice (AOO) Bugzilla – Issue 59915
image loss in writer documents, dataloss
Last modified: 2017-05-20 10:44:45 UTC
We have a big image loss problem. My current version is "2.0.1 RC5 German version WIN XP: [680m1(Build8990)]", I saw that problem in all versions starting with 1.1.4 (for earlier ones I do not remember, but I believe, the problem existed there, too). I have a System for technical documentation with lots of images in a subfolder, those images are used in the documentation document. From time to time I see the effect that lots of images in the document are lost, pls. see attached screenshot. Unfortunately this is not reproducible, sometimes I do not see that problem for days, sometimes with every document version. I can contribute some documents to compare "before loss / after loss", unfortunately the contents should not be bublished, so that I would prefer to send the "testkit" directly to a developer.
Created attachment 32803 [details] screenshots "with image loss / without image loss"
After those image loss effects very often several of the remaining images, which werde inserted by link, become embedded.
MRU please have a look, thanks ! Seems to be more a writter issue than a framework problem to me.
Reassigned to ES.
@es: Is it useful if I send some testfiles by email?
hello rainer please send some of the files to me jw@openoffice.org have to lower the prio to p3 because this is not really reproducible for me on my system. set target OOo later (will be changed, by me or a developer, if this is confirmed and reproduced here) does this happen in all applications or is this a writer issue only? reassigend to jw
Even i'm facing the same problem what rainerbielefeld is facing
Still see it in 2.0.2
Hi JW, just for the records... I remember that I saw this effect in writer, too... but this was not reproduceable and that image loss doesn't occur often...
Currently (app. during the last 4 weeks)I can't see that problem during my work.
Definitively not solved, currently this problem really drives me crazy. Writer more and becomes unusable for my needs. Attached you will find a demonstration kit containing 2 files with different advanced state of decay and disintegration I worked with one of my documents (technical documentation) using "2.0.2 German version WIN XP: [680m5(Build9011)]" when I realized that the problem happened again. I saved the current damaged document and created a "distillate" 'test damaged_dc.odt'. Afterwards, I took former version of the document and "distilled" moe or less in the same way to 'testbeforedamage_dc.odt'. Unfortunately this document Is'nt really ok, while I deleted waste or confidential parts of the document, some further images vanished, for Example our logo in front of "Schaltschrankprüfung" and "Inbetriebnahmebericht", the image before "unerledigt / kundenseitig oder bauseits" /stoerung.png/ and some else. But you will also see many images in that document which are missing in 'test damaged_dc.odt', for example many smileys after heading "ANLAGE", /problem.png/ in front of "Dringendes Problem" The "globe" in front of "http://www.BielefeldundBuss.de" is missing in the image collection.
Created attachment 40086 [details] demonstration kit that will allow to compare a more and a less damaged cocument
I created a completely new document, to be sure that no old (and may be damaged) document contents could get to the new document, I first copied text I wanted to use to an EditPad (text editor) document and then as unformatted text to my new OOo document. All the rest of the document has been created completely new. The image loss still happens also in the new document :-((
related to issue 71348 ??
dataloss P2 is a serious bugs. we need better target instaed of OOo later. How about OOo 2.2 ? Please consider it. Thanks
*** Issue 71348 has been marked as a duplicate of this issue. ***
hi utomo this would be a p2 yes, if we could reproduce this. i know some people confirming this behaviour but i can under no circumstances reproduce this here. i run a test in which i reopend and saved/closed rainers document from the demonstration kid some thousend times - compared the results -> nothing. yes the document looks different from the pdf he attached but that is not an proof. debuging has no result because the error does not occur. i had an eye on all my testdocuments since rainer posted this issue i never saw the described behaviour. we have nothing we could grab our hands on. i have the time again to take a intensive look on this issue. i read the comments posted in issue 71348 and on the OOo board and hope this will help to reproduce this.
Hi JW, just for the records... I saw this "feature" again ... A collegue used "snag it" to paste "Screenshots" into OOo Writer... He scrolled up and down and the pics werde gone... :( Unfortunately I don't have a copy of his document... "Snag it" is a screen capture tool. He used this program to take a screenshot only of that part on the screen he really wanted to have in that screenshot... Link: http://www.techsmith.com/snagit.asp Ok... this was just for the records... ;)
Again seen today with not exactly the same, but related effect: A picture has not vanished completely, but, the hyperlink to the image has been broken and only a gray frame will be visible (from the former smiley); some other images with newly vanished links still are visible. When I saved the original document (with new name), close and reopen the document, the image has been lost completely. After I reopened the original document (with old name) again, every thing looked fine, smiley at it's place.
Created attachment 43414 [details] screenshot illustraging comment rainerbielefeld Tue Feb 27 15:09:02 +0000 2007
Taking the supplied testbeforedamaga_dc.odt from Rainer Bielefeld's demonstration kit, I can reproduce this bug 100% by saving under different filename and reopening the new file with the following versions: OOo 2.1.0, OOo 2.0.4 on OpenSuSE Linux 10.0. With the following versions the bug could not be reproduced: 2.2.0rc2 , OOo_m199 (Build 9106), OOo_m7 (Build 9118), OOo 1.1.5 I compared the context.xml files of a broken and of a good one and found the following differences: OK case: *** SNIP *** SNAP *** <text:span text:style-name="T47"> ANLAGE</text:span> </text:p> <text:list text:style-name="L1"> <text:list-item> <text:p text:style-name="P58"> <text:span text:style-name="T1"> <text:s/> <text:tab/> </text:span> <text:span text:style-name="T1"> <draw:frame draw:style-name="fr1" draw:name="Grafik8" text:anchor-type="as-char" svg:width="4.39mm" svg:height="4.3mm" draw:z-index="39"> <draw:image xlink:href="Pictures/1000000000000048000000459BA23DF0.png" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/> </draw:frame> </text:span> *** SNIP *** SNAP *** BROKEN case: *** SNIP *** SNAP *** <text:span text:style-name="T47"> ANLAGE</text:span> </text:p> <text:list text:style-name="L1"> <text:list-item> <text:p text:style-name="P58"> <text:span text:style-name="T1"> <text:s/> <text:tab/> </text:span> <text:span text:style-name="T1"> <draw:frame draw:style-name="fr1" draw:name="Grafik8" text:anchor-type="as-char" svg:width="4.39mm" svg:height="4.3mm" draw:z-index="34"> <draw:image/> </draw:frame> </text:span> *** SNIP *** SNAP *** As one can see, in the broken case, there is an empty <draw:image/> statement. I have some further findings on the problem, where I don't know whether they are related: I tried to save to M$-Word DOC-Format in the OOo 2.x.x line, which completed fast. However, on opening this file, all versions of OOo 2.x.x almost immediately got stuck. Even after a very long time, I was nearly unable to scroll through this document. With OOo 1.1.5 I could open this document instantaneously, and scrolling worked well.
reassigned to OD. can you please take a look at this issue. i set the prio to p3 because i am not able to reproduce this here on my systems, but with the comments from the community i reassign this to you. the last post writer said he is not able to reproduce this with some versions of the office but this happend to rainerbielefeld to and after a certain time the error reoccured in his version. because this issue is not reproduceable for me and because this error seems to occur just by chance the target will stay at OOo later.
I tried to reproduce the described defect with the provided document <testbeforedamage_dc.odt> under Microsoft Windows and a SuSE Linux with OOo 2.0, OOo 2.1 and OOo 2.2. I opened the document, saved it under a new filename, closed it and opened it respectively reload it. Unfortunately, no image got lost. OD->JW: Please take over again. I think, we should close this issue as long as we can't reproduce it.
*** Issue 34587 has been marked as a duplicate of this issue. ***
I have seen a somehow similar problem with pictures using writer in OO2.2. I have a 400 page writer document with more than 100 pictures. The OS is WinXPpro and I switched to 2GB RAM. Many pictures are embedded using external files like .jpg or .png. There seems to be no problem with those. Some pictures are embedded internal. Several of those pictures - but not all of them - got lost when opening the document after some editing and printing work again. The problem seems to depend on the type of the anchor. I lost the pictures of Pasteur, Bechamp, Peyton Rous, Enderlein, v. Brehmer - all formatted with type as character, vertical, above ground line. I did not loose pictures formatted with type as character, vertical, lower character. The printout of the document was ok with all of the pictures. Then - suddenly - only the frames of the pictures were shown with a kind of error message inside. After doing a save and reboot some of the embedded pictures (with no external files) were lost. Even the frames were missing. Therefore the whole text layout changed. There is a Patch available for WinXPPro WindowsXP-KB909095-x86-DEU.exe that should be used in combination with 2GB RAM to keep sure that the powerdown mode will go correctly to "Ruhezustand" and not to standby instead of it. I do not know whether this could be have any effect on this problem. I did not have this patch installed when I lost my pictures.
*** Issue 81032 has been marked as a duplicate of this issue. ***
This bug is drive me crazy ... i have a master document imported from word (and i think this is a part of the problem) and extended it to my study master. If i write on this document i didnt have any problems. But a follow student work on this too and one of 3 time he broke the document. All graphics disappear and Image linking is not an option, because we use o3spaces for teamwork. We tryed different installations (Win/linux) with the same result. i can send my document for checking, but it is not for public. conloos
I did not see that problem for a very long time (1 Year?). OOo problem does no longer exist? Evolution / selection within my documents?
IMHO this issue covered several different problems. I would prefer to close it until someone again reports a problem like this.
I am working with OOo 3.0 on Windows XP and I am very familiar with this problem. Very recently I could reproduce the disappearance of embedded pictures in writer documents. That might lead as to the cause of the problem: The images disappear (sometimes all, sometimes only a part of them) as soon as my systems switches to energy-saving mode or is hibernated with the document still open. After awakening the system the pictures in the document have disappeared, first showing a frame with error message. After closing and reopening the document, the picture frame stays blank. Could you check, whether this is the reason to your problems as well. If so, some of our distinguished programmers have a new task to work on :)
Interesting observation. Looking back, I assume that we had several problems related to images and their possible disappearance, but most of them should be fixed now. If there is a remaining problem caused by hibernation, we should fix it soon. @jw: could you please try to verify the observation of openseb? In case this is reproducible, I would like to get that fixed ASAP.
I checked with "Ooo 3.0.0 RC4 Multilingual version German UI WIN XP: [OOO300m9 (Build9358)]" and can not confirm that StandBy effect. I did a quick test with a Desktop PC that supports StandBy and 2 document that were typical for those problems: Opened Documents, activated standby, reactivated PC and saw all images still at it's place. Of course, this proves nothing, I will do some 100 tests within next week. May be I find a way to make it 100% reproducible.
@openseb: after some thinking I wonder how it can be that the pictures stay empty after closing and reopening (I assume that you didn't mean *saving* and reopening). That seems to be impossible for embedded images, only for linked images something like that could happen (if the linked locations aren't available anymore after returning from hibernation).
I have had this bug happen to me on several occasions with several versions of OOo. Typically, I leave OOo Writer open overnight with a few different documents open, and when I return and scroll around I find that most all images in several of the documents have been replaced with a red square the size of the image but containing only the message "Link cannot be found" or similar. typically, these documents are some 20 pages and contain various images on most pages, I have not seen it happen on small documents. If I just close OOo entirely and reopen the documents, all is well. If I save the documents, they will be broken upon reopening - most or all images missing, no squares. I would send you an example document I got corrupted yesterday, but unfortunately its contents are classified. If you wish I could try to provoke this bug with some innocuous sample document and make screenshots. The severity of this bug is obviously high - I had to recreate a lot of images for a major job the other day, and even then I feel uncertain that that particular ODT is healthy.
@stockfeltm: it would be great to get a sample document. I haven't seen this problem for a long time, but I believe that is because of "surviving of the fittest" concerning my documents and not because the problem really has vanished.
@stockfeltm: though your document will be a "post mortem" analysis, it may give some useful information. You can send it to me (Mathias.Bauer[at]sun.com). Thanks for helping.
I think I found a workaround for this problem, maybe even a way to reproduce the error on other machines where that has been unsuccessful so far. For me the problem occured when my document reached around 80 pages with about 70 embedded images, 50 of which I had added since I saved the last time. The bug vanished after I changed the memory settings in OOo under Extras -> Options -> Memory (freely translated from German). There I increased the image cache size from 20 to 200 MB, the number of objects from 20 to 200, the "remove after" time to 1 hour and possibly the memory per object to 5,2 MB. So far the error has not since appeared again. It was even possible to add more pages and images compared to when the bug first materialized. For those who were unable to reproduce the bug, have you tried decreasing the image cache size, etc? I'm running OOo 3.1.1 (OOO310m19, build 9420) on Windows XP Home 32-bit with 3 GiB RAM.
*** Issue 119360 has been marked as a duplicate of this issue. ***
I can now reproduce this problem every time. See https://forum.openoffice.org/en/forum/viewtopic.php?f=7&t=41271&p=314079#p314079 which says that - dragging many 5MB JPG files into an odt brings up the Insert Sections pop-up and the odt file crashes. - saving after every 10 images prevents the Insert Sections pop-up appearing, and the odt file accepts 73 (I stopped at 73) images, and saves OK, but crashes on opening. - all 73 photos are intact in the 350 MB ODT file. I uploaded contents.xml to the forum post, and give details of experience saving (blue squares take 45 seconds during save, but Writer unresponsive for a further 45 seconds after). Writer 4.1.0, Windows 7 Home Premium, 64 bit, 4GB memory.
I have an alternative scenario to demonstrate the problem--the symptoms of the problem at least. What I've done is to configure OO to use a temp file location that has limited space: The open document (33 embedded images) occupies about 30Mb in temp files The limited temp area has ~15-20Mb available There's enough temp space for the main document components but not enough for all the images. In this situation, OO appears to open the document cleanly, except that some of the images have the "Read error" place holder. If I try to save the document in this state (no more temp space), I get "General i/o error ... Can't save subdocument content.xml". If I then free up some temp space and save again, no error occurs and the resulting file has simply lost some of the images. I expect that running out of disk space is unlikely to happen for current systems with large disks. But even if this is not the actual cause of the problem, I think this does demonstrate a flaw in the design of OO, that a serious, document-damaging error is not brought to the user's attention, allowing the document to be permanently damaged. I believe this could be related to the image caching: it seems that OO may not effectively deal with errors in managing the cached files. Errors in unpacking any part of the document archive (write error: no space in this situation) should be fatal errors--the document should not open.
*** Issue 126329 has been marked as a duplicate of this issue. ***
Reset the assignee to the default "issues@openoffice.apache.org".