Bug 134332 - Error when saving bigger odt/ods with password
Summary: Error when saving bigger odt/ods with password
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.0.0.alpha0+
Hardware: All All
: high major
Assignee: Dennis Francis
URL:
Whiteboard: target:7.1.0 target:7.0.0
Keywords: bibisected, bisected, regression
: 134703 134760 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-06-27 08:06 UTC by Sandra Weddig
Modified: 2020-08-10 08:59 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot showing error. (50.90 KB, image/png)
2020-06-30 08:04 UTC, Paul
Details
Example file (297.37 KB, application/vnd.oasis.opendocument.spreadsheet)
2020-07-10 21:03 UTC, Telesto
Details
Bibisect log (3.05 KB, text/plain)
2020-07-12 20:54 UTC, Telesto
Details
hang_im_tmp_file (21.76 KB, image/png)
2020-07-18 08:08 UTC, b.
Details
not_working_workflow (147.74 KB, image/png)
2020-07-19 11:29 UTC, b.
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sandra Weddig 2020-06-27 08:06:11 UTC
Description:
The programm says "Allgemeiner Ein-/Ausgabefehler" (~ Common Input / Output Error) when I try to save a bigger odt (200kb and above) with a passwort. It does fine without password or smaller documents. This happens at 2 different clients.

Steps to Reproduce:
1. use openSuSE Tumbleweed
2. install LibreOffice 7.0 Beta 2
3. generate a big odt
4. try to save it with a password

Actual Results:
the occurs an error, the file cannot be saved

Expected Results:
no error, file saved


Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
Version: 7.0.0.0.beta2
Build ID: 00(Build:0)
CPU-Threads: 8; BS: Linux 5.7; UI-Render: Standard; VCL: kf5
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded
Comment 1 raal 2020-06-27 22:13:42 UTC
I cannot reproduce with Version: 7.1.0.0.alpha0+
Build ID: 10129e2dfc582915d999e24deed34f7303a6f02e
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: x11
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded

Please can you attach test file? Thank you
Comment 2 keellambert 2020-06-28 13:46:31 UTC
I've tried LibreOffice 7.0.0.0beta2-1.1 on two very different laptops with exactly the same result

Deleting/renaming directory ~/.config/libreoffice/ had no effect

the files with problems to save are *.ods between 100k and 500k 
(that are also password protected) 
(have not yet tried files with *.odt extention)
failure warning given,
"Error saving the document 1diff:
General Error.
General input/output error."

Downgraded back to LibreOffice 6.4.4.2-2.1 on both laptops and no problems found
Comment 3 Sandra Weddig 2020-06-29 06:42:57 UTC
I will try to generate a big enough odt document witzhout sensitive data later.
The error occurs not when I revert to a 6.4 version.
Comment 4 QA Administrators 2020-06-30 03:42:35 UTC Comment hidden (obsolete)
Comment 5 Sandra Weddig 2020-06-30 07:05:17 UTC
I can only reproduce this bug with already password protected documents. These contain sensitive data. Is there any way, how I can randomize the content?
Comment 6 Paul 2020-06-30 08:04:32 UTC
Created attachment 162540 [details]
Screenshot showing error.

I'm also able to replicate this issue.

Using the Libre Office document "GS60-GettingStartedLO.odt" from:

https://documentation.libreoffice.org/assets/Uploads/Documentation/en/GS6.0/GS60-GettingStartedLO.odt 

Saving the document without a password works as expected.

Saving the document with a password fails with the error shown in the attachment.


Version: 7.0.0.0.beta2
Build ID: 00(Build:0)
CPU threads: 2; OS: Linux 5.7; UI render: default; VCL: kf5
Locale: en-GB (en_GB.UTF-8); UI: en-GB
Calc: threaded
Comment 7 Paul 2020-06-30 08:09:58 UTC
Test document provided. clearing NEEDINFO flag.
Comment 8 raal 2020-06-30 16:53:55 UTC
Confirm with Version: 7.1.0.0.alpha0+
Build ID: 63f3485b57904de4e77c04f5759e6563fcce6748
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded
Comment 9 Buovjaga 2020-07-01 11:26:26 UTC Comment hidden (obsolete)
Comment 10 Telesto 2020-07-10 20:59:37 UTC
*** Bug 134703 has been marked as a duplicate of this bug. ***
Comment 11 Telesto 2020-07-10 21:03:12 UTC
Created attachment 162895 [details]
Example file
Comment 12 Kevin Donovan 2020-07-10 21:23:11 UTC
Thanks to all who diagnosed the problem and provided an example document.

My spreadsheet contained sensitive data (which is why it was encrypted).  I tried creating a simple example, but as others have seen, it needs to be a big file.  Later today or tomorrow, I was going to modify my spreadsheet and replace sensitive data in it, but it appears that this is no longer necessary.  Thanks for saving me the trouble to do this.
Comment 13 Telesto 2020-07-12 20:42:01 UTC
*** Bug 134760 has been marked as a duplicate of this bug. ***
Comment 14 Telesto 2020-07-12 20:54:27 UTC
Created attachment 162942 [details]
Bibisect log

Bisected to
author	Dennis Francis <dennis.francis@collabora.com>	2020-01-11 11:51:34 +0530
committer	Dennis Francis <dennis.francis@collabora.com>	2020-01-13 12:11:44 +0100
commit	353d4528b8ad8abca9a13f3016632e42bab7afde (patch)
tree	a83950338ad79e77594638d9dd60bd073fdd2115
parent	9dce33e6943dec5ff111802ec3e7c338abf56592 (diff)
tdf#125662: do parallel-zip in batches
In this approach the input stream is read one batch (of constant size)
at a time and each batch is compressed by ThreadedDeflater. After
we are done with a batch, the deflated buffer is processed straightaway
(directed to file backed storage).

https://cgit.freedesktop.org/libreoffice/core/commit/?id=353d4528b8ad8abca9a13f3016632e42bab7afde
Comment 15 Telesto 2020-07-12 20:54:52 UTC
Adding CC: to Dennis Francis
Comment 16 b. 2020-07-13 09:52:58 UTC
me too - observed similar problem, 

file with password protection on net share (accessed by a win7 client with 'net use' via LAN or VPN): frequent failures (general input / output error and similar), i estimate in 15 to 30% of cases, with different LO versions, most used 6.1.6.3 and 7.1.0.0.a0+, 

'save as' with different name works in most cases, save local almost ever,
Comment 17 keellambert 2020-07-13 12:29:45 UTC
tried LibreOffice_7.0.0.1_Linux_x86-64_rpm today with the same errors
when trying to save a password protected file.
Comment 18 Telesto 2020-07-13 15:51:41 UTC
(In reply to b. from comment #16)
> me too - observed similar problem, 
> 
> file with password protection on net share (accessed by a win7 client with
> 'net use' via LAN or VPN): frequent failures (general input / output error
> and similar), i estimate in 15 to 30% of cases, with different LO versions,
> most used 6.1.6.3 and 7.1.0.0.a0+, 
> 
> 'save as' with different name works in most cases, save local almost ever,

This is only about saving a pass-worded file of a certain file size failing. And  limited to/ starting with LibO 7.0. Other - similar - issues are unrelated to this case.
Comment 19 b. 2020-07-14 06:48:41 UTC
one more flavour of failures: 

"Error saving the document dispo_kw20-30_enc:
Object not accessible.
The object cannot be accessed
due to insufficient user rights."

it worked before and nothing was changed in network setup or permissions, 

checked properties - security: 'Jeder' (everyone) has 'Vollzugriff' (full access), 

@Telesto: 

> This is only about saving a pass-worded file of a certain file size failing. And  
> limited to/ starting with LibO 7.0. Other - similar - issues are unrelated to 
> this case.

do you really want a new bug for smaller files failing too? (mine was ~90 kb), 

do you really want a new bug for versions before 7.0 failing too? 

or shall we consider this bug a special case of any? files failing with also older versions? and version 7.0 the cause for more frequent incidents? 

reg. 

b. 

P.S. did i write my file was smaller? or can you look into my computer? then you can actually better write the bug reports yourself ;-)
Comment 20 Commit Notification 2020-07-14 08:41:15 UTC
Luboš Luňák committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/08161f853571e3d4113c40a5d9d2cc24dca7506f

fix encrypted parallel zip saving (tdf#134332)

It will be available in 7.1.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 21 Xisco Faulí 2020-07-14 09:59:19 UTC
Hi Luboš Luňák,
I've just downloaded your patch to a local branch and I do verify the error is no longer prompted at export time. however, the new generated document can no longer be open and LibreOffice claims the password is incorrect. I'll report it in a follow-up bug
Comment 22 Xisco Faulí 2020-07-14 14:03:31 UTC
Added a unittest in https://gerrit.libreoffice.org/c/core/+/98743 but it's blocking on bug 134796
Comment 23 b. 2020-07-14 15:45:46 UTC
imho a fix can't be called a fix if it renders the files unusable ... should stay 'assigned' 'til working correctly ... 

[my grandma suffers from fever - try to cut her throat, she still has fever? - no, she is getting colder every minute - fixed!]
Comment 24 Commit Notification 2020-07-16 11:04:46 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/c60ce3d48dbccd616cfa989ca3d8f1ded4ccd411

tdf#134332, tdf#134796: sc_subsequent_export_test: Add unittest

It will be available in 7.1.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 25 Commit Notification 2020-07-16 11:50:10 UTC
Luboš Luňák committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/53c3c95c0a3d42161ea661ecb454ef46d4b7111f

fix encrypted parallel zip saving (tdf#134332)

It will be available in 7.0.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 26 Commit Notification 2020-07-16 17:46:58 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/8b15cebf0df0bf1449e2a1f221411e23eebbce16

tdf#134332, tdf#134796: sc_subsequent_export_test: Add unittest

It will be available in 7.0.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 27 Commit Notification 2020-07-17 09:29:41 UTC
Luboš Luňák committed a patch related to this issue.
It has been pushed to "libreoffice-7-0-0":

https://git.libreoffice.org/core/commit/31cb5467927dc87579e7343b270b81fc13b0ab79

fix encrypted parallel zip saving (tdf#134332)

It will be available in 7.0.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 28 b. 2020-07-18 08:08:18 UTC
Created attachment 163231 [details]
hang_im_tmp_file

looks like working now, 

my network share where i had the errors collected some - ~15? - files, outdated lock files (imho from broken connections), and files with names like lu11396aiaa5q.tmp, most 0 bytes, but some with content, zip files with structure alike *.ods files, but bringing errors like hanging as attached screenshot or 'xml parser error, not well formed xml content in line 1' or similar, 

might that be a problem that garbage like that is never removed? 

i don't know the procedure, but can assume calc has to check some of these file if they are related to that one it's opening, by hangs in them it would have problems, 

is there any common advice about when to remove which of those files?
Comment 29 b. 2020-07-19 11:29:53 UTC
Created attachment 163268 [details]
not_working_workflow

pardon, again persistent annoying failures ... 

(it's high in the top ten of user annoying bugs if you can't save your work) 

see documented tries in pic: 

1. save with ctrl-s, failed, 

2. tried 'save as', failed too, 

3. proof of acessibility, from bottom to top: 

- loaded file, 

- tmp-file form 'save', 

- tmp-file from 'save as', 

- text created with notepad, 

- try to save a fresh calc file, file is created, 

- as well a tmp-file, 

4. but saving fails with 'insufficient rights', 

network share on a router, FRITZ!Box 7490, accessed from a win7pro SP1 x64 host by 'net use', LAN, Wifi, 

calc ver: 

Version: 7.1.0.0.alpha0+ (x64)
Build ID: 0d45380c99c7200075d01860a2315d0ddb450f1c
CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-US
Calc:
Comment 30 b. 2020-07-19 12:21:18 UTC
feeling like in a laundry machine, up and down and up ... 

found something which might be important, 

i'm working with two sets of credentials, one is my login to the local machine, the second is different name and different pass for the login ('net use' access) to the smb share, 

it looks as if calc persistently tried to access the smb share with my local name, and that isn't valid there, 

access by win and notepad worked, read by Libreoffice too (i could 'see' the files and load them), but on attempts to save calc must have tried to use the wrong username, 280 times over the day, 

the errors disappeared after disconnecting the shares, restart of the system, and re-connecting the shares with the right batch, 

i have a vague recollection that windows itself once stumbled over something like this, 'remembered wrong or outdated credentials', but today windows always had full read and write access, only LO 'stuck', 

i'd suggest that others who suffer from similar problems try to check the log of the server providing the share ... check if they probably work with multiple credentials, and if the problems fade away if they switch to only one set, 

if that helps it's a hint, not a solution, if this is the source of evil LO has to learn to use the right names of course ...
Comment 31 Xisco Faulí 2020-07-20 09:09:47 UTC
(In reply to b. from comment #29)
> Created attachment 163268 [details]
> not_working_workflow
> 
> pardon, again persistent annoying failures ... 
> 
> (it's high in the top ten of user annoying bugs if you can't save your work) 
> 
> see documented tries in pic: 
> 
> 1. save with ctrl-s, failed, 
> 
> 2. tried 'save as', failed too, 
> 
> 3. proof of acessibility, from bottom to top: 
> 
> - loaded file, 
> 
> - tmp-file form 'save', 
> 
> - tmp-file from 'save as', 
> 
> - text created with notepad, 
> 
> - try to save a fresh calc file, file is created, 
> 
> - as well a tmp-file, 
> 
> 4. but saving fails with 'insufficient rights', 
> 
> network share on a router, FRITZ!Box 7490, accessed from a win7pro SP1 x64
> host by 'net use', LAN, Wifi, 
> 
> calc ver: 
> 
> Version: 7.1.0.0.alpha0+ (x64)
> Build ID: 0d45380c99c7200075d01860a2315d0ddb450f1c
> CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render:
> Skia/Raster; VCL: win
> Locale: de-DE (de_DE); UI: en-US
> Calc:

Hello b,
please, report it in a new ticket. The original issue is fixed here.
Comment 32 b. 2020-07-23 21:17:38 UTC
my save errors are under investigation - trying and collecting errors - and it looks like: 
a) handling of an usb-stick as a 'nas device' by a fritz!box, 
b) especially when setting the box to allow 'power save' for the interface, 
have weaknesses which block LO, 
it's cumbersome that other programs could save files ... investigating ... 
one other question: 

there are users which saved files with the buggy versions and now have problems to access their data, which might not even have a backup ... 

is it understandable what went wrong while the bug wasn't fixed, and is it possible to provide appropriate decryption for such cases? 

i'd think some users will be very! thankful ... 

or does it already do - open buggy encrypted files? 

reg. 

b.
Comment 33 Aron Budea 2020-08-10 08:59:09 UTC
I've removed a bunch of unrelated issues from the See also field.

(In reply to b. from comment #32)
> one other question: 
> 
> there are users which saved files with the buggy versions and now have
> problems to access their data, which might not even have a backup ... 
> 
> is it understandable what went wrong while the bug wasn't fixed, and is it
> possible to provide appropriate decryption for such cases? 
The commit causing this regression didn't get into any release version (regression started in 7.0, and was fixed before 7.0.0.3). There's no general answer to your question.