Bug 87392 - FILESAVE: I/O error on file save
Summary: FILESAVE: I/O error on file save
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.1.2 release
Hardware: Other All
: high critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2014-12-17 05:02 UTC by Matthew Francis
Modified: 2016-05-08 10:41 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Fixed file (40.35 KB, application/vnd.oasis.opendocument.text)
2016-04-22 18:35 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Francis 2014-12-17 05:02:02 UTC
This bug is split off from bug 84543, and as such I am setting it straight to NEW. Both issues mentioned on the original bug have already been confirmed.
(I also confirm that this issue is still present on 4.5 master)


When performing "Save as" on the following file, an I/O error dialog appears:

https://bugs.freedesktop.org/attachment.cgi?id=107167
Comment 1 Matthew Francis 2014-12-17 05:07:00 UTC
Bibisect results from 43all:
 a22bedaefd4f837e884f70bc50b0f916160b4c49 is the first bad commit
commit a22bedaefd4f837e884f70bc50b0f916160b4c49
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Thu Oct 17 21:58:35 2013 +0000

    source-hash-a4c385f1aa98b5fb2d85136b653365fb6baa33f8
    
    commit a4c385f1aa98b5fb2d85136b653365fb6baa33f8
    Author:     Caolán McNamara <caolanm@redhat.com>
    AuthorDate: Sun Aug 4 23:12:45 2013 +0200
    Commit:     Caolán McNamara <caolanm@redhat.com>
    CommitDate: Mon Aug 5 11:21:31 2013 +0200
    
        convertion section page to .ui format
    
        Change-Id: I26990ba16ba70683960685d8c26bbfd2d66d6132


# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [c2069a369d738078124812312d51f21ea1ce2421] source-hash-f160e4935c474a5293b3d3c11b3d538efb4767a0
git bisect start 'latest' 'last41onmaster'
# bad: [33ac6698e6d90d84f99d784b9553ee87eec27d6a] source-hash-732c0f929fc0229b6da37d4ec4b6de8994fcea46
git bisect bad 33ac6698e6d90d84f99d784b9553ee87eec27d6a
# bad: [e3a648fdaa2bb87293750400b70ba590733a804a] source-hash-33526481788137d959f27ae32910127d1436c1a8
git bisect bad e3a648fdaa2bb87293750400b70ba590733a804a
# good: [b886825d7eb2550ab40d7b4cd16de8096c57d6eb] source-hash-b46688a663b8709e0e0795f25ef8961db1f46cba
git bisect good b886825d7eb2550ab40d7b4cd16de8096c57d6eb
# bad: [f789e50909694bc398aaca477bc79ea38828034e] source-hash-e926621fb00f31471b0037d7955b6a3d7f908dc0
git bisect bad f789e50909694bc398aaca477bc79ea38828034e
# bad: [6dab1aaf04879f7ed6ca8baace99020b7f709443] source-hash-417d1c2b13cbd70300d2921b5667dfadc7e25895
git bisect bad 6dab1aaf04879f7ed6ca8baace99020b7f709443
# bad: [a22bedaefd4f837e884f70bc50b0f916160b4c49] source-hash-a4c385f1aa98b5fb2d85136b653365fb6baa33f8
git bisect bad a22bedaefd4f837e884f70bc50b0f916160b4c49
# good: [c685b5d1aeea7ba2813f740e4c5297152e17a6b5] source-hash-83ff6c0f4101fe4f25c2b4a58c70b40de8cc2ff2
git bisect good c685b5d1aeea7ba2813f740e4c5297152e17a6b5
# good: [c52a7f2528a470b0f3719cb0ef33d22a467994fd] source-hash-ae0493ccfe7c232557fb87eef4d0444709d8b729
git bisect good c52a7f2528a470b0f3719cb0ef33d22a467994fd
# first bad commit: [a22bedaefd4f837e884f70bc50b0f916160b4c49] source-hash-a4c385f1aa98b5fb2d85136b653365fb6baa33f8
Comment 2 Matthew Francis 2014-12-22 16:33:01 UTC
The save error appears to start here. Unfortunately this seems to only make an existing problem fatal, and isn't the source of the underlying bug.


commit a43a18edb0023b2a9533e719c8cf3dd2f894dad7
Author: Lionel Elie Mamane <lionel@mamane.lu>
Date:   Fri Aug 2 23:35:20 2013 +0200

    do *not* silently ignore errors when saving libraries
    
    In case of error, it leads to *data* *loss*.
    
    Change-Id: I80d806ef10a3364174eced3095ebf1ea217d75b4
Comment 3 Matthew Francis 2014-12-28 09:48:46 UTC
Adding Cc: to lionel@mamane.lu as the originator of the above commit (a43a18edb0023b2a9533e719c8cf3dd2f894dad7)

Based on the commit message, I'm guessing the breakage in this particular file is due to some unrelated bug which just happened to be exposed by your commit, but is there any chance you could take a look at this?

Thanks
Comment 4 Xisco Faulí 2015-09-11 12:59:05 UTC
This issue is still present in

Version: 5.0.1.2
Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261
Locale: es-ES (es_ES)

on Windows 7 (64-bit)
Comment 5 Robinson Tryon (qubit) 2015-12-13 11:10:56 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]
Comment 6 Julien Nabet 2016-04-21 22:23:34 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this.

The problem is the file with special character "Lischal?sch.xml"

It's not read as it should in http://opengrok.libreoffice.org/xref/core/package/source/zipapi/ZipFile.cxx#840. Indeed the encoding isn't preserved.
Comment 7 Julien Nabet 2016-04-22 18:35:48 UTC
Created attachment 124577 [details]
Fixed file

After other tests, I noticed that in fact there was a pb in the file.
ö ("o" with umlaut) was badly encoded.

Indeed, I renamed the ods file to zip so we can view its content.
1) I tested with Gnome tool to view the content of file, the file name wasn't ok
2) I used unzip on command line then run 'ls', again the file name was wrong.

So I renamed the file on console with "ö" + changed the content of META-INF/manifest.xml which was wrong too.
Then I recompress the whole and it seems ok.

I used master sources updated yesterday and found
1) The macro was present with its original name
2) "Save as" the fixed file had no popup message.

I let you test, perhaps I overlooked something.
Comment 8 Per 2016-05-08 09:47:30 UTC
(In reply to Julien Nabet from comment #7)
> Created attachment 124577 [details]
> Fixed file
> 
> After other tests, I noticed that in fact there was a pb in the file.
> ö ("o" with umlaut) was badly encoded.
> 
> Indeed, I renamed the ods file to zip so we can view its content.
> 1) I tested with Gnome tool to view the content of file, the file name
> wasn't ok
> 2) I used unzip on command line then run 'ls', again the file name was wrong.
> 
> So I renamed the file on console with "ö" + changed the content of
> META-INF/manifest.xml which was wrong too.
> Then I recompress the whole and it seems ok.
> 
> I used master sources updated yesterday and found
> 1) The macro was present with its original name
> 2) "Save as" the fixed file had no popup message.
> 
> I let you test, perhaps I overlooked something.

I tested your new file (and the old) and got exactly the same response on 5.0.6.3 (x64) release on win 7.
Comment 9 Per 2016-05-08 09:49:28 UTC
sorry if unclear: the fixed file worked the old failed as expected
Comment 10 Julien Nabet 2016-05-08 10:41:16 UTC
Thank you Per for your feedback, so the problem was due to some file encoding issue in the file.

Let's put this one to WFM.

Matthew: don't hesitate to reopen this tracker if I missed something.