Bug 52226 - FILESAVE Images in .docx and .xlsx files show "Read-Error", probably corrupted by auto-save[Summary in comment # 31]
Summary: FILESAVE Images in .docx and .xlsx files show "Read-Error", probably corrupte...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.5.3 release
Hardware: All All
: highest critical
Assignee: Caolán McNamara
QA Contact:
URL:
Whiteboard: SummaryUpdate target:4.4.0 target:4.2...
Keywords:
: 58895 61674 62808 63059 70501 70616 74748 81739 (view as bug list)
Depends on: 47148
Blocks: 77999 mab4.2
  Show dependency treegraph
 
Reported: 2012-07-18 09:27 UTC by okko7
Modified: 2014-08-22 15:33 UTC (History)
23 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample .docx file with missing images, created with LibO 3.5.5.3 (4.70 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2012-07-18 14:06 UTC, Roman Eisele
Details
screenshot: reproduced in 4.3.1.1 (131.32 KB, image/png)
2014-08-20 12:36 UTC, Kevin Suo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description okko7 2012-07-18 09:27:46 UTC
While working on a .docx or .xlsx file, pictures are replaced with "read error" message when opening file.

Steps to reproduce are given here:
https://bugs.freedesktop.org/show_bug.cgi?id=33393#c56:

1- started docx document in Office 2010 on Windows 7, added text, a few
pictures, and table of contents.
2- opened docx in LO 3.5.4 on Mac Lion.  Made various edits and added about 13
jpeg photos using Insert > Picture > From File in various places in the
document. I did crop one of the images in LO and edited a few with "Edit with
External Tool" (Mac Preview rotation) and all seemed okay from those. 
3- re-Saved the file as docx and dropboxed it
4- re-opened the docx file at work today and got the following results. 


Probably all recent comments on this bug https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/157249 are also about the same bug.
Comment 1 Roman Eisele 2012-07-18 10:06:08 UTC
[Quotation from https://bugs.freedesktop.org/show_bug.cgi?id=33393#c56
continued: Results after step 4:]

* MS Office 2010 will not open it now and says it has an error.

* Libreoffice 3.5.4 on Windows 7 will open it, but there are read-error notices where the pictures should be.  

* I also notice that the file is 4MB, which would be small considering that many
pictures. They would have been a few MB each.  

* Also, the few images that were added originally in step 1 are still present and
okay. All other images are missing with read-error.

----

@okko7:
Thank you very much for moving the discussion to a new bug report! I will see if I can reproduce (and therefore confirm) this new report ...

(Changed 'Component' to 'LibreOffice', because not only Writer is affected, but also Calc, and maybe Impress).
Comment 2 Michael Meeks 2012-07-18 11:59:42 UTC
Another symptom of the horrific design behind image management.
Comment 3 Roman Eisele 2012-07-18 14:06:24 UTC
Created attachment 64351 [details]
Sample .docx file with missing images, created with LibO 3.5.5.3

REPRODUCIBLE with
LibreOffice 3.5.5.3 (Build ID: 7122e39-92ed229-498d286-15e43b4-d70da21), German langpack installed, on MacOS X 10.6.8 (Intel).

To test, I used the steps given by Geoff King in
https://bugs.freedesktop.org/show_bug.cgi?id=33393#c58:
 
> 1-opened LO and made sure autosave was on, and it is by default
> 2-changed autosave to 1 minutes (as noted in other comments) although it
> doesn't work at other intervals either.  I figured it would be more likely to
> have problems if it autosaved more often
> 3-started new file and saved as docx
> 4-Added some text and formatting and a few images here and there, while
> waiting a few minutes between.  Also clicked the save button once or twice
> to save the file between waits and adding images.
> 5-After about 10 minutes and minimal additions, I saved the file, close it,
> and closed LO.
> 6-Re-opened the file in LO and the first image I added was read-error.  The
> other images were present, but some in slightly wrong places. 

My results are even worse: I added 2 PNG images and one JPEG image to the page, and all three are lost: I only see grey rectangles with the broken image symbol and the red notice "Read-Error". The images also lost the wrap settings I added to them -- both the direction of wrap-around (Before or After or Parallel ...) and the distance for text from the image margins are missing, all reset to default values. Only the position and size of all three images seems to be correct.
Comment 4 Roman Eisele 2012-07-18 14:10:44 UTC
Updated Status and Summary
Comment 5 Roman Eisele 2012-07-18 15:35:59 UTC
Also REPRODUCIBLE with LibreOffice 3.6.0.1 (Build ID: 73f9fb6), German langpack installed, again on MacOS X 10.6.8 (Intel).

Creating and editing an .docx file following the steps cited in comment #3 gives me exactly the same results as said in comment #3.

However, at least for now I can't reproduce the bug with Impress, so AFAIK Writer (.docx) and Calc (.xlsc) files are affected. (But maybe someone else can manage to reproduce this with Impress, to, so keep on testing ;-)
Comment 6 stragu 2012-11-02 02:37:44 UTC
I seem to have a similar problem on Ubuntu 12.10 with LO 3.6.2.2 :
 Since I started exchanging .odt documents between my system and a Windows system with Microsoft Office, using tracked changes and comments.

Every so often my images disappear with the message "Read-Error" and the broken image icon.
Comment 7 Barry Rueger 2012-11-24 23:32:32 UTC
Version 3.6.0.2 (Build ID: 360m1(Build:102)) on Mint Linux Maya, same problem.

BIG problem!
Comment 8 Barry Rueger 2012-12-15 19:36:41 UTC
FYI using Version 3.6.0.2 (Build ID: 360m1(Build:102)) on Mint Linux, problem remains.
Comment 9 Mark V. 2013-03-02 03:45:13 UTC
*** Bug 61674 has been marked as a duplicate of this bug. ***
Comment 10 Mark V. 2013-03-02 03:52:36 UTC
Issue is still present with Version 4.0.0.3.
> *** Bug 61674 has been marked as a duplicate of this bug. ***
Comment 11 Florian Reisinger 2013-04-21 14:37:25 UTC
*** Bug 58895 has been marked as a duplicate of this bug. ***
Comment 12 Milos Sramek 2013-05-12 06:27:04 UTC
It looks like the problem is not specifically related to autosaving, but to saving in odt in general, since a similar problem was reported in Bug 63058 and Bug 62808. The problem can be reproduced by:

1. open and odt file with images
2. change it
3. save it (as odt)
4. save as docx
5. close the document
6. open the docx version: images are  missing

If step 3 is omitted, the docx file is OK.
So I suggest that Bug 63058 and Bug 62808 be marked as duplicates of this one.
Milos
Comment 13 Winfried Donkers 2013-05-13 06:53:25 UTC
*** Bug 62808 has been marked as a duplicate of this bug. ***
Comment 14 brendel 2013-05-13 19:35:02 UTC
This issue has been there through all of the V4 versions up to 4.0.2.
I can observe this bug every day : I receive docx files from colleagues which contain inserted images. I open them using LibreOffice and save them again as docx, usually using a different name, open them again : images have disappeared, either giving a read error or just an empty box ( I have observed both problems within the same file). 
When I open the resulting docx file with a zip programm and have a look in the mdeia folder I can see actually many  imageXX.png or .emf files that either only contain a white rectangle or are corrupted. 
I have done this very fast after opening, I would guess before autosave has saved, the problem does not occur, so I actually also believe that this has something to do with the autosaving. 
This is a very annoying bug as everytime I return a document to a colleague all of the images are lost. I hope that this will be resolved rapidly. 

Cheers

Oliver
Comment 15 Winfried Donkers 2013-05-14 06:37:22 UTC
Still present in version 4.0.3, 'losing' images in docx and xlsx files severely reduces interoperability LibreOffice - MS Office.
Comment 16 Timur 2013-05-15 15:33:56 UTC
*** Bug 63059 has been marked as a duplicate of this bug. ***
Comment 17 Kumāra 2013-05-29 03:31:43 UTC
I notice the same and a DOCX file. If I save and keep it as ODT, no problem.

I've not NEEDed to use DOCX. If ODT is not an option for you, I suggest that you use DOC as a temporary workaround.

If you notice that graphics saved in DOCX with earlier versions of LO, please mark this as a REGRESSION in Whiteboard.

Something odd in this reporting: I see version indicated as "3.5.3 release", but detailed reports shows "3.5.4" to be the earliest version the bug is observed. Please confirm if this is a mistake.

Perhaps it was mistakenly indicated by someone reporting the bug for 3.5.5.3. As I've learn, the version indicated should be the first version the bug is noticed. In any case, please correct it to avoid confusions.
Comment 18 Rob Whalley 2013-06-27 20:35:11 UTC
Out of interest, please could someone else test using v4.1.0.1? Previously I had been able to reproduce this issue with a docx file easily, but after trying today I was unable to reproduce the problem and am keen to find out if this was a fluke or not. Tested on Win8 64bit.
Comment 19 untraceable 2013-06-28 00:00:06 UTC
Thanks a lot for looking into this matter, Rob.

I hope this time, the bug will get tackled sooner. Unlike my original report (bug 58895), which went unnoticed for over 4 months and in the meanwhile the file from the download link had been automatically removed. ^^
(30 days no download)

I reuploaded the unchanged files to http://ul.to/er0yvxmb

The bug with the read error DOES exist in the official Pre-Release Version:
----
Version: 4.1.0.1
Build ID: 1b3956717a60d6ac35b133d7b0a0f5eb55e9155
OS: Windows 7, 64bit (but with the x86 executables, as the only ones available)
Language: German for both
----

The saved and broken png-Image (rename *.docx to *.zip and open \word\media\) consists as before only of the first 8 bytes, a part of the png header, instead of the 8034 bytes of the original png.

I padded the original png with zeros at the end to about 16KiB (i.e. all the same logical files and sizes, but physical filesize is bigger.) and when the changed document - removed/added a space somewhere - is saved, the picture gets saved without the zeros at the end, i.e. the filesize is read/computed from the png header before saving. ( http://ul.to/5kv96od7 ) Therefore, it's not the physical file that is kept!


Tracking the pn RAM andng contents/datastructure i debugging the program step by step should reveal, why only the first 8 bytes are saved. 

My guess for the bug:
Overwriting or not setting the stored file length or using/setting/computing the wrong value. (including the one that is calculated from the png-header informations)


I don't have enough time in the next weeks/months to setup the LibreOffice development tools and look into the source code, but if you can provide me a download link to the next binaries (english only would be OK), I can test it again on my PC for sure.
Comment 20 untraceable 2013-06-28 00:16:13 UTC
>Tracking the pn RAM andng contents/datastructure i debugging the program step by >step should reveal, why only the first 8 bytes are saved.

Sry for the misplacement, it should read as follows:
---
Tracking the png contents/datastructure in RAM and debugging the program step by step should reveal, why only the first 8 bytes are saved.
---
Comment 21 Rob Whalley 2013-06-28 07:15:12 UTC
I'll try to help but am not a coder on the project, apologies if I gave that impression. The debugging method suggested is probably beyond me right now (in skill and available time). Looking at the example files you've provided though, it certainly does look as though the PNG file only consists of the PNG signature as described here: http://www.libpng.org/pub/png/book/chapter08.html#png.ch08.div.2 (confirmed by loading the file in a hex editor and it matches perfectly).
Comment 22 Rob Whalley 2013-06-28 09:00:25 UTC
Have confirmed this does still occur in 4.1.0.1 under both of the methods described above.
To re-iterate...

METHOD 1:
Ensure Save AutoRecovery information is on, and set to save every 1 minute to make testing easier.
Open an ODT document with an image, save as DOCX format.
Add a space to the document text.
Wait until the automatic recovery save is performed.
Save the DOCX file.
Once re-opened the images will be missing.

METHOD 2:
Open an ODT document with an image, save as DOCX format.
Export a PDF document, either using the button in the toolbar or the File > Export as PDF menu option.
Add a space to the document text.
Save the DOCX file.
Once re-opened the images will be missing.
This behaviour occurs when when Save AutoRecovery information is switched off.

It should be noted I did not get consistent results with how many images were not displayed. In one of my first tests, all images were removed. In subsequent tests, just the image on the first page was removed.
Comment 23 untraceable 2013-07-05 12:19:38 UTC
After reading comment 21, that no file specific content is saved and the 8 bytes are exactly the png file signature, I tried something else.

Instead of a png file in the MS docx file I used a JPEG file (saved as such inside the docx * ) and got interesting results:
When a read error occurs, the JPEG file is now an empty 8 bytes PNG file! The file name stays the same and only the file extension is changed to png. This means in my case, the PDF export most probably replaces a pointer/reference or the file content and overwrites it with an empty png datastructure.

Files of the experiments can be found at http://ul.to/cmxo0uat .


I see two (relatively) simple solutions to this problem:
- Find the address of the JPEG datastructure in RAM and track it and all its references/pointers/members/fields. One of these gets changed when it shouldn't and you have the culprit codeline.
- (As workaround) Make a deep copy of the complete, currently displayed document and use this for auto-save and pdf export. The PDF in my experiments was exported correctly.

Please inform some other developers, who could work on this issue as it is really annoying having to keep a manual backup of all files, when working together with someone who uses MS Office with docx as standard file format and the Office Version might not be able to open odt files.



* rename *.docx to *.zip and go to /word/media/ in the archive
Comment 24 tommy27 2013-08-09 15:14:25 UTC
moving this bug from the mab3.6 list to the mab4.0 list since 3.6.x is EOL and bug is confirmed in 4.0.x and 4.1.x releases.
Comment 25 tommy27 2013-12-31 11:59:21 UTC
*** Bug 70501 has been marked as a duplicate of this bug. ***
Comment 26 tommy27 2013-12-31 12:03:03 UTC
*** Bug 70616 has been marked as a duplicate of this bug. ***
Comment 27 Björn Michaelsen 2014-01-17 09:58:50 UTC
(This is an automated message.)

Setting priority to highest as this is a 4.0 MAB. This is part of an effort to make the importance of MAB reflected in priority too.
Comment 28 Dale 2014-02-07 06:43:01 UTC
A college has just experienced a similar problem three times in the last week, all in the same .ods document. It probably happened during autosaves. The file has about 110 images, a mixture of svm and png.
The missing images are represented as "<draw:image xlink:href=""><text:p/>" and the images also disappeared from the Pictures folder.
This is with LO 4.1.1.2 running on Windows XP.
I have not been able to reproduce the problem.
Comment 29 stragu 2014-02-12 07:11:53 UTC
I just came across this issue with most png images in a docx file, using Writer 4.1.5.1 (Build ID: e0a1805d063a472a7b281ae3977a26d42a48b20).

Moving this issue to MAB 4.1 as 4.0 reached its EOL a while ago.
Comment 30 libreoffice 2014-02-15 16:35:08 UTC
The document in issue in 46547 now makes my LibreOffice write crash.
Comment 31 HannahL 2014-02-18 03:38:23 UTC
Summary
This bug has been confirmed in several versions on many platforms.

Comment 3 gives steps used to reproduce with worse results than reported in description, and comment 5 confirms that those steps work in a different version. 

Comment 6 reports a problem exchanging .odt documents between systems; comment 12 suggests the problem is with odt rather than autosaving and gives steps to reproduce problems with odt. 

Comment 14 reports problems with docx files and believes the problem is related to autosave. 

Comment 22 gives 2 methods of reproducing bugs when changing between odt and docx. 

Comment 23 reports problems with JPEG files becoming empty 8 byte png files and suggests two ideas for solutions. 

Comment 28 reports problems with ods files as well.
Comment 32 sophie 2014-03-18 13:06:28 UTC
*** Bug 74748 has been marked as a duplicate of this bug. ***
Comment 33 tommy27 2014-05-08 12:12:52 UTC
still reproducible under Win7x64 using LibO 4.2.3.3 and 4.3.0.0.alpha1+
Build ID: a1dd961c3093f5f7624e4d1f2240e9120fd13f23
TinderBox: Win-x86@39, Branch:master, Time: 2014-05-06_11:47:48

moving to mab4.2 list since 4.1.x is END OF LIFE
Comment 34 colin.mercer 2014-05-08 20:46:39 UTC
As a professional engineer I write many reports and most have the need for images. A picture is worth ....
Because of this persistent bug I and many of my colleagues have given up using LO. I am an advocate of open source and I am keenly disappointed that this major bug has not been even allocated to anyone, let alone resolved.

Like many things a bug often produces illogical results that manifest themselves differently in different circumstances. 

The only way I have found to make LO probably produce a report with images is to have all images saved somewhere, together with a decent picture viewer, and then to write the text leaving sufficient space on a page to accomodate the images later, but not in their correct position of course.  Once all the text is in place and I have a saved docx then I re-open and insert each picture in its appropriate place, only ever moving forward in the document and ensuring the picture does not cause leaps from page to page.  Fortunately the default wrap aids this process.  Also make sure any page headings, footers, numbering and the like are done before putting in any images..  Then export ASAP as a pdf, which seems pretty reliable, certainly before you save...  As you may imagine this process is pretty tiresome and a degree stressful.  If I need to make further modifications then I use the Serif PagePlus publication software as that allows import of pdfs and subsequent re-export as pdf.

From my experiences any deviation or similar that causes some significant structural change in the document seems to create a finite probability of one or more images being lost. 

I am not convinced this is just an autosave problem because of evidence without it.  It is perhaps a possibility however that on occasion autosave does make changes, but it may be more likely that the damage is done already. But because the affected pages were not being visibly present it was not noticed that going back a bit and re-editing actually caused the problem.  It is also likely that there is more than one error.

Just to add to the story this 'image leak' problem occurs also when I am using a doc or an odt file. Sometimes it does not leak, but in the next hour my hopes are again dashed.  I have never seen it happen on a one page doc with one image.

Apologies for the lengthy message. I have really tried to use LO but my patience is wearing mighty thin. Please, please do something.
Comment 35 hunter.croil 2014-05-08 22:10:24 UTC
This explanation hit the nail on the head. I agree and have been steering people like myself who use images in their docs away from LO for this very reason. It simply can’t be trusted. And like this person stated, IMMEDIATELY exporting to a PDF is the only way to ensure the desired result … but then no more editing without starting over at the beginning.


(As a note, some functions in Tables have similar inconsistencies. I’ve written about this before, but had less than desirable results.)


I do hope a copy of this note goes to every officer in the LO organization. Sadly.


Otherwise LO is very good.










From: bugzilla-daemon@freedesktop.org
Sent: ‎Thursday‎, ‎May‎ ‎8‎, ‎2014 ‎3‎:‎46‎ ‎PM
To: Croil Hunter







Comment # 34 on bug 52226 from colin.mercer@botley.com  As a professional engineer I write many reports and most have the need for
images. A picture is worth ....
Because of this persistent bug I and many of my colleagues have given up using
LO. I am an advocate of open source and I am keenly disappointed that this
major bug has not been even allocated to anyone, let alone resolved.

Like many things a bug often produces illogical results that manifest
themselves differently in different circumstances. 

The only way I have found to make LO probably produce a report with images is
to have all images saved somewhere, together with a decent picture viewer, and
then to write the text leaving sufficient space on a page to accomodate the
images later, but not in their correct position of course.  Once all the text
is in place and I have a saved docx then I re-open and insert each picture in
its appropriate place, only ever moving forward in the document and ensuring
the picture does not cause leaps from page to page.  Fortunately the default
wrap aids this process.  Also make sure any page headings, footers, numbering
and the like are done before putting in any images..  Then export ASAP as a
pdf, which seems pretty reliable, certainly before you save...  As you may
imagine this process is pretty tiresome and a degree stressful.  If I need to
make further modifications then I use the Serif PagePlus publication software
as that allows import of pdfs and subsequent re-export as pdf.

From my experiences any deviation or similar that causes some significant
structural change in the document seems to create a finite probability of one
or more images being lost. 

I am not convinced this is just an autosave problem because of evidence without
it.  It is perhaps a possibility however that on occasion autosave does make
changes, but it may be more likely that the damage is done already. But because
the affected pages were not being visibly present it was not noticed that going
back a bit and re-editing actually caused the problem.  It is also likely that
there is more than one error.

Just to add to the story this 'image leak' problem occurs also when I am using
a doc or an odt file. Sometimes it does not leak, but in the next hour my hopes
are again dashed.  I have never seen it happen on a one page doc with one
image.

Apologies for the lengthy message. I have really tried to use LO but my
patience is wearing mighty thin. Please, please do something.



You are receiving this mail because: You are on the CC list for the bug.
Comment 36 Caolán McNamara 2014-06-04 16:09:46 UTC
FWIW there's a reasonable chance this is fixed in 4-2-5/4.3.0
Comment 37 Bryan 2014-06-17 17:20:05 UTC
I am sad to report that with the latest version downloaded yesterday that the problem with images disappearing is still present.
I have tried using links instead to embedding images but with the same result.
After saving when I come back and reopen my presentation the link shows but does not display a picture.  If I duplicate the slide the image link works and the picture displays.  When I close and return the link may or may not work. Or maybe some other link does not work. It is random.
  So- embedded images disappear at random.
       Linked images disappear at random.
I am sad. I will have to use the product from Redmond Washington to get my work done.
    Running on Windows 8.1  will presently try on Opensuse and see if the results are better.  If there is any change in the behavior I will post a note here.
Comment 38 stragu 2014-06-17 22:11:47 UTC
Hi Bryan
Which version exactly did you test this on?
Cheers
Comment 39 Bryan 2014-06-19 00:29:42 UTC
Version: 4.2.4.2
Build ID: 63150712c6d317d27ce2db16eb94c2f3d7b699f8 is what is on my laptop.
I just now started L.O.  and opened my presentation. Once again most of the links display pictures but some do not. The ones that do not display are different than the ones that did not display when I last opened the presentation.

When I first started trying to build a presentation I embedded pictures only to have the pictures disappear entirely.  With links at least the link info is there and I can duplicate the slide and have it work until the next time I save. 
then it is random as to what works and what does not the next time I open the presentation.
Comment 40 stragu 2014-06-19 05:42:47 UTC
Thanks Bryan.
We will be able to test this with 4.2.5 really soon an check if Caolán was right.

Caolán, can we have more details about your assumption?
Comment 41 Timur 2014-07-10 11:30:29 UTC
Following https://bugs.freedesktop.org/show_bug.cgi?id=63059#c0 and using https://bugs.freedesktop.org/attachment.cgi?id=77355 I still reproduce the problem with LO 4.2.5.2.

To reproduce:
1. open the attached document
2. change it (add a space)
3. save it (as ODT)
4. save as DOCX - WITHOUT CHANGING
5. close the document
6. open the DOCX version: images are  missing
Comment 42 Cor Nouws 2014-07-11 13:13:49 UTC
(In reply to comment #41)
> Following https://bugs.freedesktop.org/show_bug.cgi?id=63059#c0 and using
> https://bugs.freedesktop.org/attachment.cgi?id=77355 I still reproduce the
> problem with LO 4.2.5.2.


Simple to reproduce - also with 4.3.0.2

thanks
Comment 43 Cor Nouws 2014-07-11 13:34:51 UTC
Useful comment on role of autosave
  https://bugs.freedesktop.org/show_bug.cgi?id=46447#c85

Comment with summary of some of the cases
  https://bugs.freedesktop.org/show_bug.cgi?id=52226#c31


I've seen the problem recently with a writer document and a presentation. Not too complicated, both losing one of the images while editing.
I've spend time and time to try to reproduce. Not..

As I've written somewhere else in one of the many occurrences of this problem:
Knowing that there are various in memory copies of a document, and in Impress maybe related to various views (side panel, normal view, slide sorter, ..) it may be well possible that there is a problem in synchronising those copies.
This is supported by some other comments too.

This will help to _not_ reproduce the problem ;) ... but alas neither is a guaranty that it won't happen, nor does it help as a reliable solution to do reproduce it..
Comment 44 Cor Nouws 2014-07-11 13:38:56 UTC
hmm, my comment 43 was meant for bug 47148
Comment 45 Caolán McNamara 2014-07-14 10:10:26 UTC
I can reproduce #41 so I will fix that
Comment 46 Commit Notification 2014-07-14 10:49:51 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9dd5caac62083f7162d83319284df68ee83e3777

Resolves: fdo#52226 swap in graphics on .docx and .rtf export



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 47 Commit Notification 2014-07-14 14:19:19 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6e580f3f53ae2de086a08c8ba1958b67874eb9c5

Related: fdo#52226 ensure graphics are swapped in on DrawingML::WriteImage



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 48 Caolán McNamara 2014-07-14 14:23:35 UTC
So, the reproducible one is fixed. The xlxs I cannot reproduce, but the speculative fix might resolve that if someone is able to reliably reproduce it for testing purposes
Comment 49 Commit Notification 2014-07-15 10:09:43 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=5b11f8b75b1ee6da439c3cd7892990b601e03d83&h=libreoffice-4-2

Resolves: fdo#52226 swap in graphics on .docx and .rtf export


It will be available in LibreOffice 4.2.7.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 50 Commit Notification 2014-07-15 10:18:11 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b0282d868b418b4ecdb19cbb633c9399ac84161b&h=libreoffice-4-2

Related: fdo#52226 ensure graphics are swapped in on DrawingML::WriteImage


It will be available in LibreOffice 4.2.7.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 51 Commit Notification 2014-07-15 10:18:32 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=cd6f03d6f9ceea88e486788b09606c1efcaa4f1f&h=libreoffice-4-3

Related: fdo#52226 ensure graphics are swapped in on DrawingML::WriteImage


It will be available in LibreOffice 4.3.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 52 Commit Notification 2014-07-15 12:13:05 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-3-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a90c1bbb74b4dd13b8b3879740ad596a4cedd69a&h=libreoffice-4-3-0

Resolves: fdo#52226 swap in graphics on .docx and .rtf export


It will be available already in LibreOffice 4.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 53 Commit Notification 2014-07-22 17:09:49 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=41fde63b3ec4da0a4a6636105dd7b65fdfc7ad44&h=libreoffice-4-3

Resolves: fdo#52226 swap in graphics on .docx and .rtf export


It will be available in LibreOffice 4.3.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 54 tommy27 2014-07-23 11:36:55 UTC
Coalan, would you please take a look at Bug 46447 which looks a similar loss of image issue related to auto-save in Impress?

the current fix for Bug 52226 had no effect on it, but I wonder if these 2 issues are somewhat related and fixable in a similar way.
Comment 55 tommy27 2014-07-27 19:57:11 UTC
*** Bug 81739 has been marked as a duplicate of this bug. ***
Comment 56 okko7 2014-07-30 11:30:17 UTC
@Coalan: I wish to thank you for your work on this bug. I haven't had the occasion to test this yet, but do so as soon as possible. 

Out of curiority: Can you explain in a few words what that bug was about and maybe a bit about the magic you did to solve it? 

Thanks again!
Comment 57 Kevin Suo 2014-08-20 12:36:01 UTC
Created attachment 104978 [details]
screenshot: reproduced in 4.3.1.1

Hi all,

This issue is not fixed. Today I reproduce in version 4.3.1.1 Win7, when I was trying to translate the LibreOffice 4.2 Guide in Writer:
https://wiki.documentfoundation.org/images/0/0f/GS42-GettingStartedLO.odt

It seems images lost at the time when LO is saving auto-recovery info while you are editing the file *at the same time*.  Set auto-recovery intevel to 1 minute to observe the lost of images (as I said, you have to keep editing when LO is auto-saving.)

The patch is surely included in version 4.3.1.1, as it was build on 07-Aug-2014 11:20. So the patch may not solve the problem.

Thanks!
Comment 58 Kevin Suo 2014-08-20 12:58:00 UTC
By the way, I do not reproduce in any way in version 4.1.6.2 release. 
In 4.3.1.1 it's very easy to reproduce. It blocks users from editing files with many images in it. Seems like a regression in 4.3.

Should a new bug report be filed?
Comment 59 Caolán McNamara 2014-08-20 14:25:40 UTC
please do not reopen bugs, file new ones, especially in a case like this where there multiple problems and a huge number of comments
Comment 60 tommy27 2014-08-21 18:15:43 UTC
@Kevin
if you open a new report please put the link to this one under "See Also"
Comment 61 Kevin Suo 2014-08-22 15:33:56 UTC
(In reply to comment #59)
> please do not reopen bugs, file new ones, especially in a case like this
> where there multiple problems and a huge number of comments

I filed bug 82953 to report the problem I reproduce in 4.3.1.1.