Bug 82953 - EDITING: ODF - Autosave causes PNG and SVG images to be lost with read error
Summary: EDITING: ODF - Autosave causes PNG and SVG images to be lost with read error
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.1.1 rc
Hardware: All All
: high blocker
Assignee: Not Assigned
URL:
Whiteboard: odf target:4.4.0 target:4.3.5
Keywords: bibisected, bisected, dataLoss, filter:odt, regression
: 74703 81877 82964 84928 85025 85250 86064 (view as bug list)
Depends on: Image-Caching
Blocks:
  Show dependency treegraph
 
Reported: 2014-08-22 15:13 UTC by Kevin Suo
Modified: 2015-12-17 05:55 UTC (History)
32 users (show)

See Also:
Crash report or crash signature:


Attachments
images in this document are lost (372.87 KB, application/vnd.oasis.opendocument.text)
2014-08-22 15:25 UTC, Kevin Suo
Details
how it looks after the autosave happens (172.98 KB, image/png)
2014-08-22 15:35 UTC, Yousuf Philips (jay) (retired)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Suo 2014-08-22 15:13:38 UTC
(I am filing this bug to report a similar (maybe the same issue) as Bug 52226. Bug 52226 was fixed some days ago, but I still reproduce it with 4.3.1.1 release, so that commit seems not fix the issue.)

DESCRIPTION: 
Images in a document will be lost (showing "read error"), at the time auto-save is triggered. For me and for this case, it happens in ODT document.

STEPS TO REPRODUCE:

1. Set auto-save interval to 1 minute.

2. Downloand and open this LibreOffice 4.2 User Guide ODT document here:
https://wiki.documentfoundation.org/images/6/6d/GS4202-SettingUpLibreOffice.odt

3. Hit ENTER to make the document modified, then wait for the auto-save to come.

4. When auto-save is finished, scroll up and down to observe that many images are showing "read error", images are gone, leaving only a placeholder and the error msg.

5. Save the document and reopen, "read error" messages are gone, and the images as well as place holders are no longer there.

The only workaround is to disable auto-save.

I set this to "BLOCKER" because by default auto-save is set 15 minutes, so users will lost their images after 15 minutes for sure.

I do not reproduce following the above steps in versoin 4.1.6.2, so it's a regression.


Version:
4.3.1.1, Build ID: c4b15cd4d00dec6b266fa830b4ba73e31ae6ce73
Win7
Comment 1 Kevin Suo 2014-08-22 15:25:37 UTC
Created attachment 105109 [details]
images in this document are lost

This is the document after auto-save, images in page 4,7,9,10...are lost.
Comment 2 Yousuf Philips (jay) (retired) 2014-08-22 15:35:27 UTC
Confirmed this behaviour in 4.2.6, 4.3.2 and master and not in 4.1.6 on Linux. It happens with some PNG files and not others, the first image lost is on page 4 (figure 1).
Comment 3 Yousuf Philips (jay) (retired) 2014-08-22 15:35:52 UTC
Created attachment 105112 [details]
how it looks after the autosave happens
Comment 4 tommy27 2014-08-23 06:45:29 UTC
(In reply to comment #0)
> (I am filing this bug to report a similar (maybe the same issue) as Bug
> 52226. Bug 52226 was fixed some days ago, but I still reproduce it with
> 4.3.1.1 release, so that commit seems not fix the issue.)

probably the patch did not fixed the bug 100% and there's residual issues still pending.

is this happening just with some PNG files (Jay said some are unaffected) or with others image extensions as well? 

(In reply to comment #3)
> Confirmed this behaviour in 4.2.6, 4.3.2 and master and not in 4.1.6 on
> Linux. It happens with some PNG files and not others, the first image lost
> is on page 4 (figure 1).

the fix for Bug 52226 is present in 4.2.7, 4.3.0 and 4.4.0 master.
so 4.2.6 is still unpatched.
Comment 5 tommy27 2014-08-23 14:04:51 UTC
*** Bug 82964 has been marked as a duplicate of this bug. ***
Comment 6 Jan Jurkus 2014-10-10 12:16:08 UTC
I can reproduce this on LibreOffice 4.3.2 (the latest release), using the steps Kevin Suo pointed out.

I have a few users reporting missing images, so will test whether turning off autosave fixes this as well. The document I have is missing placeholders, and any sign there has been a lot of images included.
Comment 7 Urmas 2014-10-12 08:36:34 UTC
*** Bug 74703 has been marked as a duplicate of this bug. ***
Comment 8 Urmas 2014-10-12 08:36:54 UTC
*** Bug 84928 has been marked as a duplicate of this bug. ***
Comment 9 Yousuf Philips (jay) (retired) 2014-10-13 06:48:11 UTC
Seems images are being lost in ODPs as well (bug 46447). Wonder if these two are related?
Comment 10 Cor Nouws 2014-10-13 08:31:59 UTC
(In reply to Jay Philips from comment #9)
> Seems images are being lost in ODPs as well (bug 46447). Wonder if these two
> are related?

Yes in the sense that image caching in general is a problematic part of the code. There is bug 47148 for that.
Comment 11 tommy27 2014-10-15 18:47:05 UTC
*** Bug 85025 has been marked as a duplicate of this bug. ***
Comment 12 Milan Bouchet-Valat 2014-10-20 20:35:53 UTC
*** Bug 85250 has been marked as a duplicate of this bug. ***
Comment 13 tommy27 2014-10-20 20:53:54 UTC
(In reply to tommy27 from comment #4)
> ....
> 
> is this happening just with some PNG files (Jay said some are unaffected) or
> with others image extensions as well? 

SVG affected as well. see duplicate Bug 85250.

edited summary notes.
Comment 15 Matthew Francis 2014-10-26 03:13:24 UTC
Plain bisect in the vicinity of the above range points to the following specific commit:

commit 192abfb36b8a4859879fcb49326d59ed62083c8d
Author: Oliver-Rainer Wittmann <orw@apache.org>
Date:   Mon May 19 11:37:11 2014 +0000

    Resolves: #i114361# provide and accept changed URL...
    
    of embedded graphic file during save (ODF export)
    
    (cherry picked from commit a90c007908eb3f66e28a9ea525729065db652b6f)
    
    Conflicts:
        sw/inc/ndgrf.hxx
        sw/source/core/graphic/ndgrf.cxx
        sw/source/core/unocore/unoframe.cxx
        sw/source/filter/xml/xmltexte.cxx
        xmloff/source/draw/shapeexport2.cxx
    
    Change-Id: I9d4a02af2561467fe1a66f036b55d6dcf2429986
Comment 16 Steve Edmonds 2014-11-02 22:10:16 UTC
Possibly related. I have not filed a bug yet as still testing.
I have had auto-save and backup copy turned off for years since first discovering the bug. Now in 4.1.6.2 if I right click an image>Compress graphic I will get a read error on graphics somewhere else in the document and loose the image. If I don't compress I don't loose images.
Comment 17 Xisco Faulí 2014-11-03 08:39:19 UTC
It seems that the commit that caused this regression was identified. (Or at
least a commit is suspected as the offending one.)

Thus setting keyword "bisected".
Comment 18 Caolán McNamara 2014-11-05 15:39:51 UTC
Is this reproducible in 4.3.3 or 4.2.7 or master. Because while the above commit did break graphic save, there was some follow up patches which were supposed to fix it again,  e.g.
 05e07167e422caf58d23ff883edda30acc3ba88d

and I can't reproduce with 4.2.7 and master with an x86_64 dbgutil build
Comment 19 Xisco Faulí 2014-11-05 15:57:01 UTC
I can't reproduce this issue with master ( Version: 4.4.0.0.alpha1+
Build ID: b7d8a58ff2698ffc6e22943f64aa97c5ea253bd9 ) in Ubuntu 14.10 x86_64
Comment 20 Milan Bouchet-Valat 2014-11-05 16:16:55 UTC
Caolan: At least on 2014-10-20 it wasn't fixed in 4.3.x:
https://bugs.freedesktop.org/show_bug.cgi?id=85250#c6
tommy27 can probably give more details, but that bug is easy to reproduce anyways.
Comment 21 Jan Jurkus 2014-11-05 16:54:58 UTC
Also reproducable on 4.3.3
Comment 22 Kevin Suo 2014-11-06 11:14:55 UTC
*** Bug 81877 has been marked as a duplicate of this bug. ***
Comment 23 Rpnpif 2014-11-06 14:29:57 UTC
Reproducible here again. LO Version: 4.3.3.2
Build ID: 9bb7eadab57b6755b1265afa86e04bf45fbfc644.
(Debian Wheezy 7 with official wheezy-backports on AMD A4-5300 APU with Radeon(tm) HD Graphics on MSI A78M-E35 motherboard).
Comment 24 Commit Notification 2014-11-16 19:33:57 UTC
Zolnai Tamás committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=286e2f5c6ec829bc0987b1be7016699f7ef03e5e

Related fdo#82953: Forget package URL of image after it is loaded

It will be available in 4.4.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 25 Tamás Zolnai 2014-11-16 21:00:31 UTC
Hi there,

I pushed a commit, which can fix this issue.
I'm not 100% sure because I can't reproduce this problem on master or on 4.3.4 branch, but can with 4.2.6. So as caolan said potentially it is already fixed by his follow up patches.
This patch I pushed is a general solution for all problems caused by that odt imported images are handled on a different way (as directly inserted ones for example).
A similar problem what I found is that sometimes the thumbnail in the exported odt shows read error at the place of the images, but after opening the file it , images are there. In case of this thumbnail problem I could verify that the commit worked, so hopefully it can improve the situation here too.
Comment 26 Jan Jurkus 2014-11-16 21:56:28 UTC
I can reproduce it on 4.3.4.. So I think I want your 4.3.4 ;-)
Comment 28 Joel Madero 2014-11-20 15:12:18 UTC
*** Bug 86064 has been marked as a duplicate of this bug. ***
Comment 29 Julien Nabet 2014-11-20 16:10:43 UTC
(In reply to Jan Jurkus from comment #26)
> I can reproduce it on 4.3.4.. So I think I want your 4.3.4 ;-)

Whiteboard shows "target:4.3.5", so could you give a try to daily build of 4.3 (see http://dev-builds.libreoffice.org/daily/libreoffice-4-3/) ?
Comment 30 Jan-Philipp Litza 2014-12-07 12:38:36 UTC
> Whiteboard shows "target:4.3.5", so could you give a try to daily build of
> 4.3 (see http://dev-builds.libreoffice.org/daily/libreoffice-4-3/) ?

Tried it, didn't work. One image survived that didn't before, but others were still lost.

In case it matters, the documents that I encountered this bug in were created with OpenOffice under Windows, I'm editing them with LibreOffice under Linux.
Comment 31 Jan Jurkus 2014-12-10 00:35:16 UTC
I downloaded the following prerelease versions from https://www.libreoffice.org/download/libreoffice-fresh/

LibreOffice_4.2.8.2_Win_x86.msi
LibreOffice_4.3.5.1_Win_x86.msi
LibreOfficeDev_4.4.0.0.beta2_Win_x86.msi

4.2.8.2 and 4.3.5.1, It works! I can't believe it! And _they_ said imitiation diamond wasn't good enough!

4.4.0.0.beta2, Uh oh! Cheap mail-order jewels!

In other words, it seems to have been fixed on the 4.2 and 4.3 branches, but not on the 4.4!
Comment 32 Matthew Francis 2014-12-10 04:40:18 UTC
(In reply to Jan Jurkus from comment #31)

I can't reproduce this using the original instructions on 4.4.0beta1 or beta2 on OSX, or on master on Linux

Could you possibly confirm that you are still using the original instructions and file, and that you've checked (from within LibreOffice) that it's definitely 4.4.0beta2 that's running?


If the answer to both is yes, then perhaps someone (Jay Philips?) would be good enough to try to reproduce again on Windows with 4.4.0beta2
Comment 33 tommy27 2014-12-10 04:43:30 UTC
(In reply to Jan Jurkus from comment #31)
> ....
> 
> In other words, it seems to have been fixed on the 4.2 and 4.3 branches, but
> not on the 4.4!

try a most recent 4.4.x daily build from here
http://dev-builds.libreoffice.org/daily/libreoffice-4-4/

and copy and paste information about the build from help/anout LibO dev here.
Comment 34 tommy27 2014-12-10 04:44:53 UTC
@Kevin Suo
you are the original reporter of this bug.
please retest with newer LibO releases and tell if this issue is really fixed.
Comment 35 Kevin Suo 2014-12-10 07:45:50 UTC
(In reply to tommy27 from comment #34)
Will do later,thanks.
Comment 36 Jan Jurkus 2014-12-10 12:03:35 UTC
(In reply to tommy27 from comment #33)
> try a most recent 4.4.x daily build from here
> http://dev-builds.libreoffice.org/daily/libreoffice-4-4/
> and copy and paste information about the build from help/anout LibO dev here.

Did that, and the problem seems fixed. To make absolutely sure I was using that version I reinstalled the VM.

Working version:
Version: 4.4.0.0.beta2+
Build ID: 8cb37cc090f754c4dafe5731c827539f01743671
TinderBox: Win-x86@42, Branch:libreoffice-4-4, Time: 2014-12-09_04:54:46
Locale: en_US

Als rechecked this version:
Version: 4.4.0.0.beta2
Build ID: be92f32b8f21603a6b7a75dd645f7475bdee519d
Locale: en_US

And this seems to also work! So the report about 4.4 not working is probably due to something I did wrong. Sorry, mea culpa!
Comment 37 Jan-Philipp Litza 2014-12-10 13:56:35 UTC
Tried today's nightlies, this time both branches (4.4 and 4.3, previously I only tested 4.3). Result:

Works with both, the document supplied by Kevin and the one I had problems with:
Version: 4.4.0.0.beta2+
Build ID: a87db12c78d073dbfea50c833c25360285787054
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-4-4, Time: 2014-12-10_01:03:50
Locale: de_DE

Not working, neither with the provided one nor with my own document:
Version: 4.3.6.0.0+
Build ID: dcc914ab55feb844d5d71e6568801fa1ffd47f6c
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-4-3, Time: 2014-12-09_00:31:21
Comment 38 retired 2014-12-11 10:05:43 UTC
From what I read here, several users have tested 4.4b2 and found the problem to be fixed. Thus setting to Fixed and assigning Zolnai who provided the patch.

Re-open if this still happens for you with LO 4.4b2 or newer.
Comment 39 retired 2014-12-11 10:24:25 UTC
Due to mixed feedback for 4.3.6+0 I tested this:

OSX 10.10.1 LO Version: 4.3.6.0.0+
Build ID: 8283eeec48d8b0cd6a001eeb3c6a532d17a2656c
TinderBox: MacOSX-x86@49-TDF, Branch:libreoffice-4-3, Time: 2014-12-11_01:20:06

http://cl.ly/image/3B1q3i122h2H

Activated auto-save, waited, and all images did show fine. So ok to close this.

Jan-Philipp could you retry with the latest 4.3.6 nightly and try again if this works for you. Maybe only persisting on Linux now? Or maybe also another issue is persisting but this one is closed?
Comment 40 Jan-Philipp Litza 2014-12-11 13:28:30 UTC
(In reply to foss from comment #39)
> Due to mixed feedback for 4.3.6+0 I tested this:
> 
> OSX 10.10.1 LO Version: 4.3.6.0.0+
> Build ID: 8283eeec48d8b0cd6a001eeb3c6a532d17a2656c
> TinderBox: MacOSX-x86@49-TDF, Branch:libreoffice-4-3, Time:
> 2014-12-11_01:20:06
> 
> http://cl.ly/image/3B1q3i122h2H
> 
> Activated auto-save, waited, and all images did show fine. So ok to close
> this.
> 
> Jan-Philipp could you retry with the latest 4.3.6 nightly and try again if
> this works for you. Maybe only persisting on Linux now? Or maybe also
> another issue is persisting but this one is closed?

Okay, then this seems to be a platform-dependent problem. I tested

Version: 4.3.6.0.0+
Build ID: 8283eeec48d8b0cd6a001eeb3c6a532d17a2656c (same as foss!)
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-4-3, Time: 2014-12-11_05:02:38

with the Getting Started document and still had the problem of 26 (out of 31) images disappearing.

https://jplitza.de/tmp/lowriter_read_error.png
Comment 41 Rpnpif 2014-12-11 15:18:03 UTC
(In reply to Jan-Philipp Litza from comment #40)
I can confirm that with Debian Linux Wheezy.
So I reopen.
Comment 42 Rpnpif 2014-12-11 15:42:29 UTC
But no.

This critical bug is fixed in 4.4 nightly but not in 4.3.6, that I have used, for now.
Comment 43 jfialho 2014-12-19 15:40:48 UTC
Installed 4.5.3 (Windows) and it still LOSES images (tested with file from bug  description).

Also tested with another files (our logos on templates...)and it loses images as described on bug submit.

I hope this bug will be re-open as its NOT solved.
Comment 44 Jan Jurkus 2014-12-19 19:15:04 UTC
> Installed 4.5.3 (Windows) and it still LOSES images (tested with file from
> bug  description).

4.5.3, wow! ;-)
I can confirm it is indeed not fixed with 4.3.5:
Version: 4.3.5.2 
Build ID: 3a87456aaa6a95c63eea1c1b3201acedf0751bd5

However, could it be that the fix was not included in this version?
Comment 45 Tamás Zolnai 2014-12-19 19:57:44 UTC
Hi,

I think there were more causes of this image loss bug. One should be fixed now, but it seems others not.
I've done some cleanup in image handling on master / 4.4 which can solve the whole problem, but this whole clean up can't be backported to 4.3.
I can't reproduce the image loss, so I can't find out which patch fixed it. If anybody has time to bibisect the commit which fix the problem on 4.4 branch, it would be helpful.
Comment 46 jfialho 2014-12-19 23:53:38 UTC
(In reply to Jan Jurkus from comment #44)
> > Installed 4.5.3 (Windows) and it still LOSES images (tested with file from
> > bug  description).
> 
> 4.5.3, wow! ;-)
> I can confirm it is indeed not fixed with 4.3.5:
> Version: 4.3.5.2 
> Build ID: 3a87456aaa6a95c63eea1c1b3201acedf0751bd5
> 
> However, could it be that the fix was not included in this version?

WOW indeed! my mistake - 4.3.5.2 indeed...thx for correction, i didnt notice till i saw the WOW
Comment 47 tommy27 2014-12-20 07:15:17 UTC
I suggest the users that were able to reproduce the bug with 4.3.5 to retest the same with 4.4.0 beta to see if the issue is effectively fixed in the 4.4.x branch or if it's still some residual issue even in that branch
Comment 48 jfialho 2014-12-22 10:13:05 UTC
Tested with 4.4.0.1 1ba9640ddd424f1f535c75bf2b86703770b8cf6f PT-PT (both on XP and Windows 7), with file in attachment and also with our templates with logos and it WORKED fine. 

So it seems this bug doesnt affect 4.4.x as it does on 4.3.x
Comment 49 tommy27 2014-12-22 17:00:07 UTC
so good news is that bug is gone in 4.4.x (4.4.0 will be released in february 2015) and bad news is that some issues persist in 4.3.5

if users want to see this fixed in next 4.3.x releases (4.3.6 due in feburary 2015) a 4.4.x bibisect to find the exact committ fixing the residual issue has to be performed in order to allow a 4.3.x backport if technically feasible (see comment 45)

so I set status again to FIXED since this works in the 4.4.x branch.
Comment 50 tmacalp 2014-12-22 17:43:51 UTC
I'm not completely sure if this is the same bug, but I'm seeing read errors after auto-save with our WMF logo in an old document.  Like all of the other comments here, I still experience the error with LO 4.3.5.2, but could not reproduce it using LO 4.4.0 beta2.  These tests were performed using 32bit Fedora 17.

Since this is a pretty horrible bug, I would hope that this could be fixed in 4.3.x.  Still, thanks for all of the hard work fixing this for 4.4.x!
Comment 51 tmacalp 2015-01-12 15:53:24 UTC
I finally downloaded the 4.4 bibisect environment.  It looks like the commit that fixed this issue just barely made it in that commit range.  I would be quite happy if this fix could still be backported to 4.3.x. 

 03feacde7d0d974d28adae78a32a9e0a85e68208 is the first bad commit
commit 03feacde7d0d974d28adae78a32a9e0a85e68208
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Fri Oct 17 19:56:34 2014 +0000

    source-hash-d9b9f50242ece39f9ecbbb24128ae3eff4c3319e
    
    commit d9b9f50242ece39f9ecbbb24128ae3eff4c3319e
    Author:     Markus Mohrhard <markus.mohrhard@collabora.co.uk>
    AuthorDate: Fri May 23 20:51:30 2014 +0200
    Commit:     Markus Mohrhard <markus.mohrhard@googlemail.com>
    CommitDate: Sat May 24 10:48:43 2014 +0200
    
        avoid the creation of empty text
    
        Change-Id: If1be3f50ed4ceac40b513b341f411fc2d2533f7f

:100644 100644 5f4f478cbec24fb1867a4df4e258de7ac502366e 3fe6715d358873988070fa1a52834f85d6aa0264 M      ccache.log
:100644 100644 a0ef9f957436f15c18f64d38ac115a97e64cb1be e5af6940636fe7a1ed8f31af18096b0dc23c2c8a M      commitmsg
:100644 100644 35b812d17ebfbc5ae40f80b9f71a536a02af3830 176ca9c888502dcdb39403d827fdf9120da706c0 M      make.log
:040000 040000 cc74f7751e1c5ee9ad35d72a512c52ce71b1bce3 2d735ae783b56d4752a99488f414399d4edaed18 M      opt


$ git bisect log
# bad: [4a3091e95fa263d3e2dd81e56e83996f0bb12287] source-hash-2b5b04e1e62914bf0902dfd7943cdc44499c47a6
# good: [812c4a492375ac47b3557fbb32f5637fc89d60d9] source-hash-dea4a3b9d7182700abeb4dc756a24a9e8dea8474
git bisect start 'latest' 'oldest'
# bad: [5d0dfb8e62ae61a240f8313c594d4560e7c8e048] source-hash-0c6cd530de13f80795881f61064f1bf1dcc4ea81
git bisect bad 5d0dfb8e62ae61a240f8313c594d4560e7c8e048
# bad: [c0ef5c9ad28738878bb28206d62a57aa367cad92] source-hash-d47678c990681d0cfc7f2c843bb9aedaeb08511a
git bisect bad c0ef5c9ad28738878bb28206d62a57aa367cad92
# bad: [652c8d1675dc8b174de907d4204dbc2ec98fe325] source-hash-0aa3dee5e88a1494a7a6a8401e084cbdb4324727
git bisect bad 652c8d1675dc8b174de907d4204dbc2ec98fe325
# bad: [0219641f7ec1bee5654f7b8c02d246fa27b03ab1] source-hash-9835fa87ac6ffe43bd9cc85839b2fea1fca2fcad
git bisect bad 0219641f7ec1bee5654f7b8c02d246fa27b03ab1
# bad: [dbe3cc9b9a4b356f550657d57783c89bd293b46b] source-hash-e23806fb815f7e419bb04de11dcb5707c4120eaa
git bisect bad dbe3cc9b9a4b356f550657d57783c89bd293b46b
# bad: [0c6eb6d43e107345f59a3a09bd2c2577302819c2] source-hash-9cff642cd51bc70327789f9dc64349bb9b4cb3ea
git bisect bad 0c6eb6d43e107345f59a3a09bd2c2577302819c2
# good: [7b9ad53b3ba4d291f49052ad9aee36b5cdcd4ac2] source-hash-9b62a5207745da6b926d2a311e5ddd16da1ae05b
git bisect good 7b9ad53b3ba4d291f49052ad9aee36b5cdcd4ac2
# bad: [03feacde7d0d974d28adae78a32a9e0a85e68208] source-hash-d9b9f50242ece39f9ecbbb24128ae3eff4c3319e
git bisect bad 03feacde7d0d974d28adae78a32a9e0a85e68208
# good: [1d95d38d2a260e012972c5d2ba4c6e1b0a64929c] source-hash-81c492ef18b04cc283561018d69818cbca7f83ef
git bisect good 1d95d38d2a260e012972c5d2ba4c6e1b0a64929c
# first bad commit: [03feacde7d0d974d28adae78a32a9e0a85e68208] source-hash-d9b9f50242ece39f9ecbbb24128ae3eff4c3319e
Comment 52 Michael Meeks 2015-01-12 19:38:14 UTC
So if I read it right the fix is in this range:

git log 81c492ef18b04cc283561018d69818cbca7f83ef..d9b9f50242ece39f9ecbbb24128ae3eff4c3319

I would guess this patch:

https://issues.apache.org/ooo/show_bug.cgi?id=114361

commit 192abfb36b8a4859879fcb49326d59ed62083c8d
Author: Oliver-Rainer Wittmann <orw@apache.org>
Date:   Mon May 19 11:37:11 2014 +0000

    Resolves: #i114361# provide and accept changed URL...
    
    of embedded graphic file during save (ODF export)
    
    (cherry picked from commit a90c007908eb3f66e28a9ea525729065db652b6f)

Is what fixed it (thanks to Oliver). Would love input on whether cherry-picking that to -4-3 fixes it for us.

Andras - this one might be interesting for us too.
Comment 53 Andras Timar 2015-01-13 10:52:40 UTC
In libreoffice-4-3 we have http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-3&id=51bc76f170c8fc71bc37c058c5e6cd1f14b773fb which is the backport of Oliver's commit a90c007908eb3f66e28a9ea525729065db652b6f. Further investigation is needed.
Comment 54 jfialho 2015-02-23 09:41:41 UTC
I tested the original files as our templates with logos (which got this error) on 4.3.6.2 and it WORKED fine (unlike previous 4.3.x versions)

Also on 4.4.x that problem is NOT seen.
Comment 55 Teo91 2015-03-07 18:12:00 UTC
I can confirm this bug is no more on LO 4.4.1 with Win8.1 and Win7.

Instead, it's only partially fixed in LO 4.3.6.2: some images loss and others correctly saved. Example ODT went down from 1.4 MB to 400 kb or so.
Comment 56 Robinson Tryon (qubit) 2015-12-17 05:55:23 UTC
Migrating Whiteboard tags to Keywords: (filter:odt, DataLoss, bibisected)
[NinjaEdit]