Bug 94834 - Gnumeric files can't be opened in Windows
Summary: Gnumeric files can't be opened in Windows
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
5.1.0.0.alpha0+ Master
Hardware: Other Windows (All)
: medium normal
Assignee: David Tardon
QA Contact:
URL:
Whiteboard: target:5.3.0 target:5.2.2
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-06 18:20 UTC by kompilainenn
Modified: 2017-05-13 20:33 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
test file gnumeric (2.35 KB, application/x-gnumeric)
2015-10-06 18:25 UTC, kompilainenn
Details
Gnumeric spreadsheet with a single sheet with data and a bar chart (2.76 KB, application/x-gzip)
2017-05-13 15:19 UTC, Pedro
Details
Screenshot showing what file calc_with_chart.gnumeric looks like when opened in Gnumeric (39.71 KB, image/png)
2017-05-13 15:27 UTC, Pedro
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kompilainenn 2015-10-06 18:20:05 UTC
Версия: 5.1.0.0.alpha1+
ID сборки: 8a334eb222906909bf77006687411ff9e03d9da3-GL
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-10-05_12:35:55
Локаль: ru-RU (ru_RU)

variant №1

1. start LibreOffice
2. select "Open file" on Start Screen
3. Search and select your .gnumeric file
4. push key Open
5. file open in Writer as xml

variant №2

1. open Calc
2. select File->Open 
3. Search and select your .gnumeric file
4. push key Open
5. file open in Calc as text import in format xml.

variant №3

1. open Calc or start LO
2. select File->Open
3. select type of file .gnumeric in drop-down list
4. Search and select your .gnumeric file
5. push key Open
6. file not open. will show an error message "total input error output"
Comment 1 kompilainenn 2015-10-06 18:25:13 UTC
Created attachment 119366 [details]
test file gnumeric
Comment 2 tagezi 2015-10-06 18:32:41 UTC
I confirm it.

Kubuntu 14.04
Comment 3 Julien Nabet 2015-10-10 07:00:20 UTC
On pc Debian x86-64 with master sources updated yesterday, I could reproduce this.

I noticed these kinds of logs:
Throwing InvalidHeaderException
warn:oox.storage:10807:1:oox/source/helper/zipstorage.cxx:66: ZipStorage::ZipStorage exception opening input storage: 
VisioDocument: version 0
Found xml parser severity error Document is empty
Comment 4 tagezi 2015-10-10 09:02:33 UTC
As I understand it, Markus Mohrhard made patch
http://cgit.freedesktop.org/libreoffice/core/commit/?id=c6726bdbd2143ae2875f3373b07b23611eb263d7

A log of  the developers channel:
[20:15:06] <tagezi> moggi: I am sorry for molestation. Do you saw this bug tdf#94834 ?
[20:15:08] <IZBot> LibreOffice-filters and storage normal/medium NEW gnumeric import not work https://bugs.documentfoundation.org/show_bug.cgi?id=94834
[20:15:47] <moggi> tagezi: yes, but I'm picking the bugs that I want to fix
[20:24:30] <tagezi> moggi: thank. I think that it is needed to be removed from from the ReleaseNotes, as in fact the new functional is not there, but there is only a new bug. thanks again

From it I can conclude that Marcus is not interesting to get feedback or further development of this functional.
Comment 5 Julien Nabet 2015-10-10 12:33:44 UTC
On pc Debian x86-64 with master sources updated today, I don't reproduce this.
It seems that indeed http://cgit.freedesktop.org/libreoffice/core/commit/?id=2db1e3447298f2b25287ff6ad4c5dda1e675f5e3 fixed this.

I cherry-picked this to gerrit review for 5.0, see:
https://gerrit.libreoffice.org/#/c/19296/
Comment 6 Julien Nabet 2015-10-10 13:03:19 UTC
Markus: here is the bugtracker about https://gerrit.libreoffice.org/#/c/19296/
If it's your patch which fixed this, I don't know what it could be.
Comment 7 Yousuf Philips (jay) 2015-10-10 16:19:23 UTC
Closing as Julien said it was fixed and Marcus mention in 5.0 gerrit patch that it couldnt be backported.
Comment 8 kompilainenn 2015-10-10 17:19:42 UTC
(In reply to Yousuf (Jay) Philips from comment #7)
> Closing as Julien said it was fixed and Marcus mention in 5.0 gerrit patch
> that it couldnt be backported.

check the facts fixes is not required or what?

I'll wait Libre Office release date after 10/10/2015 and check himself
Comment 9 kompilainenn 2015-10-27 19:11:16 UTC
this bug is not fixed!

Version: 5.1.0.0.alpha1+ (x64)
ID build: 0b018d202dfcf4bb16b708e10085a4146243b0a0
TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2015-10-25_23:32:01
Locale: ru-RU (ru_RU)
OS: Windows 7 HB x86-64
Comment 10 Buovjaga 2015-11-10 12:19:59 UTC
(In reply to kompilainenn from comment #0)
> Версия: 5.1.0.0.alpha1+
> ID сборки: 8a334eb222906909bf77006687411ff9e03d9da3-GL
> TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-10-05_12:35:55
> Локаль: ru-RU (ru_RU)
> 
> variant №1
> 
> 1. start LibreOffice
> 2. select "Open file" on Start Screen
> 3. Search and select your .gnumeric file
> 4. push key Open
> 5. file open in Writer as xml
> 
> variant №2
> 
> 1. open Calc
> 2. select File->Open 
> 3. Search and select your .gnumeric file
> 4. push key Open
> 5. file open in Calc as text import in format xml.
> 
> variant №3
> 
> 1. open Calc or start LO
> 2. select File->Open
> 3. select type of file .gnumeric in drop-down list
> 4. Search and select your .gnumeric file
> 5. push key Open
> 6. file not open. will show an error message "total input error output"

Reproduced.

Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+
Build ID: 6da681442b17c723f9408a806e8d2367441ad65a
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-11-07_23:13:46
Locale: fi-FI (fi_FI)
Comment 11 Buovjaga 2015-11-10 12:35:55 UTC
Linux works perfectly.

Ubuntu 15.10 64-bit 
Version: 5.1.0.0.alpha1+
Build ID: a148fe149c7af1995fd2aaab0a6e52242509b993
TinderBox: Linux-rpm_deb-x86_64@70-TDF-dbg, Branch:master, Time: 2015-11-08_23:54:51
Locale: en-US (en_US.UTF-8)
Comment 12 kompilainenn 2016-07-12 20:35:59 UTC
LO 5.2.0.2 on Windows 7 HB x86-64

repro
Comment 13 Pedro 2016-08-19 16:47:02 UTC
Bug confirmed using v5.2.1.1, v5.1.5.2 and v5.1.0.3 (current and first release in the 5.1 branch) under Windows 7 Pro x64 SP1

Confirmed with the provided file and any of my .gnumeric files.

This featured announced in the 5.1 release never worked under the Windows OS

Opening with File Open or drag-and-drop always results in a XML view in Writer and opening as a Gnumeric file always results in "General Error. General input/output error."
Comment 14 Aron Budea 2016-08-21 03:37:03 UTC
Debugging in VS (master build from ~two weeks ago) revealed that in:
workdir\UnpackedTarball\liborcus\src\liborcus\format_detection.cpp
GNUMERIC_ENABLED is not defined. Somehow liborcus is built without Gnumeric support on Windows.
Comment 15 kompilainenn 2016-08-21 09:42:13 UTC
(In reply to Aron Budea from comment #14)
> Debugging in VS (master build from ~two weeks ago) revealed that in:
> workdir\UnpackedTarball\liborcus\src\liborcus\format_detection.cpp
> GNUMERIC_ENABLED is not defined. Somehow liborcus is built without Gnumeric
> support on Windows.

and? it can be easy to fix?
Comment 16 kompilainenn 2016-08-21 09:45:16 UTC Comment hidden (no-value, obsolete)
Comment 17 Aron Budea 2016-08-26 05:20:00 UTC
I tried to trace this down, since the issue itself seems to be trivial. However...

GNUMERIC_ENABLED gets defined if __ORCUS_GNUMERIC is defined, and that gets defined in src/liborcus/Makefile.am if WITH_GNUMERIC_FILTER is defined.
WITH_GNUMERIC_FILTER is defined during configure, and that's where I got lost, no clue what happens in there, and how it's called.
LO repo's external/liborcus/* offered no clues, either, there's nothing related to Gnumeric.

Markus, any suggestions on how to analyze this further? Or if it's a straightforward fix for an expert, don't mind me.
Comment 18 kompilainenn 2016-08-26 08:50:09 UTC Comment hidden (abusive)
Comment 19 Commit Notification 2016-08-26 11:00:37 UTC
David Tardon committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=4462447b8a48ad097e56c47e3736d80dc4aaa13a

tdf#94834 enable liborcus format detection on Windows

It will be available in 5.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 20 kompilainenn 2016-08-26 11:06:48 UTC
(In reply to Commit Notification from comment #19)
> David Tardon committed a patch related to this issue.

> tdf#94834 enable liborcus format detection on Windows
> 
> It will be available in 5.3.0.
> 

will you backport this to 5.1 and 5.2?
Comment 21 Commit Notification 2016-08-26 13:20:29 UTC
David Tardon committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

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

tdf#94834 enable liborcus format detection on Windows

It will be available in 5.2.2.

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 22 Aron Budea 2016-09-06 01:02:01 UTC
Unfortunately enabling gnumeric support in orcus was only part of the solution, now there's the following error during file open:
"General Error.
Generic input/output error."

I can look into what's causing it in a few days.
Comment 23 Aron Budea 2016-09-13 04:12:11 UTC
I came across two strange issues in orcus:

1. It fails to find the file with name "Комп для Паши.gnumeric".

This is where it throws an exception:
https://gitlab.com/orcus/orcus/blob/master/src/parser/stream.cpp#L73

I assume the issue is the lack of Unicode filename-handling.


2. If file is renamed to ASCII characters, it proceeds further, but the string returned by the previous function is 11 bytes long, and the file still fails to load.

Changing L67 as follows fixes this issue:
std::ifstream file(filepath, std::ios::binary);

https://gitlab.com/orcus/orcus/blob/master/src/parser/stream.cpp#L67
Comment 24 Aron Budea 2016-09-16 22:35:22 UTC
Bug report opened upstream.
Comment 25 Pedro 2016-09-17 18:17:44 UTC
Modified the Summary. The previous change could mislead people to think that it was a problem with a particular file. LibreOffice can't (never could) open ANY Gnumeric file under Windows.
Comment 26 Pedro 2017-05-13 09:02:29 UTC
Update using LibreOffice version 5.3.3.2: 
1) the sample document still fails to open (as reported in Comment#23)
2) after renaming the file, the spreadsheet opens but doesn't show any content
3) any gnumeric file that I opened shows empty.

This is a problematic situation! It could lead to people concluding that the content of the file was deleted.

I think it is better to NOT open and show a message that LibreOffice can not open Gnumeric files (under Windows only?) than showing an EMPTY spreadsheet.
Comment 27 Julien Nabet 2017-05-13 15:02:50 UTC
(In reply to Pedro from comment #26)
> Update using LibreOffice version 5.3.3.2: 
> 1) the sample document still fails to open (as reported in Comment#23)
> 2) after renaming the file, the spreadsheet opens but doesn't show any
> content
> 3) any gnumeric file that I opened shows empty.
> 
> This is a problematic situation! It could lead to people concluding that the
> content of the file was deleted.
> 
> I think it is better to NOT open and show a message that LibreOffice can not
> open Gnumeric files (under Windows only?) than showing an EMPTY spreadsheet.

On Windows 10 + LO 5.3.3.2, I could open the file when renaming filename to have only ascii. Sheet 1 is empty but there's a sheet 2 which contain information.
If I don't rename the file name, I can't open the file at least from Calc and got general input error message.

So I don't reproduce your problem. Did you start from clean LO profile?
Would you have other gnumeric example files we could test?
Comment 28 Pedro 2017-05-13 15:16:37 UTC
(In reply to Julien Nabet from comment #27)

> On Windows 10 + LO 5.3.3.2, I could open the file when renaming filename to
> have only ascii. Sheet 1 is empty but there's a sheet 2 which contain
> information.
> If I don't rename the file name, I can't open the file at least from Calc
> and got general input error message.

You are correct. The file is not empty. LibreOffice creates an empty Sheet1 that is displayed ontop of the existing sheets (so the document looks empty). This is not so bad but it is unexpected and could mislead users.
 
> So I don't reproduce your problem. Did you start from clean LO profile?
> Would you have other gnumeric example files we could test?

I did test with an empty profile. The problem still occurs. I'm adding another sample file. In this case in addition to the previous problem it shows another LibreOffice import problem (the simple chart is not displayed).
Comment 29 Pedro 2017-05-13 15:19:40 UTC
Created attachment 133295 [details]
Gnumeric spreadsheet with a single sheet with data and a bar chart

When opening this sample with LibreOffice 5.3.3.2 under Windows 10, an empty Sheet1 is added before the original Gnumeric Sheet1 and the included chart is not displayed.
Comment 30 Markus Mohrhard 2017-05-13 15:26:08 UTC
(In reply to Pedro from comment #29)
> Created attachment 133295 [details]
> Gnumeric spreadsheet with a single sheet with data and a bar chart
> 
> When opening this sample with LibreOffice 5.3.3.2 under Windows 10, an empty
> Sheet1 is added before the original Gnumeric Sheet1 and the included chart
> is not displayed.

Charts are not supported by orcus and therefore the gnumeric import right now.
Comment 31 Pedro 2017-05-13 15:27:48 UTC
Created attachment 133297 [details]
Screenshot showing what file calc_with_chart.gnumeric looks like when opened in Gnumeric

This is what is expected when opening the file in LibreOffice. A single Sheet1 with two data columns and a bar chart.
Comment 32 Julien Nabet 2017-05-13 15:36:36 UTC
(In reply to Pedro from comment #31)
> Created attachment 133297 [details]
> Screenshot showing what file calc_with_chart.gnumeric looks like when opened
> in Gnumeric
> 
> This is what is expected when opening the file in LibreOffice. A single
> Sheet1 with two data columns and a bar chart.

See Markus' response just before your comment. The lib Orcus (used to import Gnumeric) doesn't support charts.
So this part is either a wontfix or an enhancement.
Comment 33 Markus Mohrhard 2017-05-13 20:33:44 UTC
The original issue has been fixed by David. Please don't reopen a bug report if the bug has been marked as fixed by a developer unless you can reproduce the bug with exactly the same steps as the original reporter.

In this case the remaining issues are non-ascii file names which are a completely different problem and require a different solution.