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
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
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
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.
[Automated Action] NeedInfo-To-Unconfirmed
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?
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
Test document provided. clearing NEEDINFO flag.
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
Also reproduced on Windows. The bibisecting of this report is reserved for new QA team members in training. Bibisecting should be done using the win64-7.0 repo.
*** Bug 134703 has been marked as a duplicate of this bug. ***
Created attachment 162895 [details] Example file
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.
*** Bug 134760 has been marked as a duplicate of this bug. ***
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
Adding CC: to Dennis Francis
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,
tried LibreOffice_7.0.0.1_Linux_x86-64_rpm today with the same errors when trying to save a password protected file.
(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.
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 ;-)
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.
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
Added a unittest in https://gerrit.libreoffice.org/c/core/+/98743 but it's blocking on bug 134796
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!]
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.
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.
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.
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.
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?
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:
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 ...
(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.
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.
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.