When opening a calc password protected file, previously saved, providing a mistyped password, a dialog appears indicating that the file is corrupted and asks if you want to try to repair it. If you answer yes, the LO closes and nothing happen, leaving a .~lock.xfile.ods# file. If you try to open it again and provide the correct password, it will open correctly. I don't know if the “repairing” causes problems to the file, but a mistyped password should be handled with the normal “incorrect password” dialog any number of times until canceling the opening request. If you create a new calc file file 4.4.0.3 and save it with password, when opening, the mistyped password handling is correct. I am attaching a writer file with the testing steps, screenshoots and findings.
Created attachment 113238 [details] steps screenshoots and findings
Created attachment 113239 [details] calc test file
TESTING with 4.4.0.3 + Ubuntu 14.04 (In reply to Robert Gonzalez MX from comment #0) > When opening a calc password protected file, previously saved, providing a > mistyped password, a dialog appears indicating that the file is corrupted > and asks if you want to try to repair it. If you answer yes, the LO closes > and nothing happen, leaving a .~lock.xfile.ods# file. > ... > If you create a new calc file file 4.4.0.3 and save it with password, when > opening, the mistyped password handling is correct. [opens 'steps screenshots and findings' document] Whoa! Those are some extensive repro steps! :P So let's just focus on a single piece of this puzzle, as that's the easiest way to get started here. REPRO Steps: 1) Try to open the Calc Test File (attachment 113239 [details]) with LibreOffice 4.4.0.3 2) Use an incorrect password ("foobar") -> Will see a 'password is incorrect' dialog 3) Close the dialog, and try using the correct password ("elessar2018") -> document will open 4) Change cell A1 to be 'x', and save the document as 'saved-test.ods' (use the same password, "elessar2018") 5) Close 'saved-test.ods', and then try to reopen it using an incorrect password ("foobar") (Based on Robert's tests, this should give us a 'file corrupted' dialog, but for me, I still got a 'password is incorrect dialog') So for me, I'll say 'NOREPRO' with 4.4.0.3. It's *possible* that's it's a Windows-specific issue, but most problems are cross-platform. Status -> NEEDINFO Robert: Two things 1) Can you confirm that the simplified repro steps above will demonstrate the problem on Windows? 2) If you have an opportunity to test on a different OS (e.g. Mac or Linux), it would be interesting to know if you see the same problem.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team This NEEDINFO message was generated on: 2015-09-03
20150905 testing Taking again this issue. Let's start from the beginning again. Problem description: When I try to open a password protected calc file, and I mistyped the password, a corrupt file message like this displays in a dialog box: The file '2015 09 05 Test New.ods' is corrupt and therefore cannot be opened. LibreOffice can try to repair the file. The corruption could be the result of document manipulation or of structural document damage due to data transmission. We recommend that you do not trust the content of the repaired document. Execution of macros is disabled for this document. Should LibreOffice repair the file? YES OR NO DIALOG If YES nothing happens, leaving a “.~lock.2015 09 05 Test New.ods#” read only file. No correction is made. And LO closes. If NO Second message displays “The file '2015 09 05 Test New.ods' could not be repaired and therefore cannot be opened.” OK button. Third message “General Error” OK button. LO closes. Tested with the same results: LO 5.0.2 LO 5.0.1 LO 4.4.5 LO 4.3.7 LO 4.2.8 LO 4.1.6 LO 4.0.6 LO 3.6.7 AOO 4.1.1 When tested with he following versions a different dialog message displays: LO 3.3 AOO 3.2 Read-Error. Format error discovered in the file in sub-document content.xml at 1,0 (row, col) OK button. This tests were made in Windows XP SP3, Windows 7, Windows 8, Windows 8.1 and Windows 10. Tests with LO 5.0.1.2 on Linux OpenSuse 13.2 is reproducible. In the same way Steps to reproduce Open test file ‘2015 09 09 Test New.ods’ with LO Version: 4.3.7.2 Build ID: 8a35821d8636a03b8bf4e15b48f59794652c68ba password 20150905 insert one sheet or make some changes Save the file open again Type incorrect password “The password is incorrect. The file cannot be opened.” OK button Repeat this last 2 steps again several times. Same dialog response. This is the correct behavior. Steps to reproduce with LO 4.4.5 Open test file 2015 09 05 Test New.ods Type incorrect password “The password is incorrect. The file cannot be opened.” OK button Repeat this last 2 steps again several times. Same dialog response. This is the correct behavior. Type correct password 20150905 File opens insert one sheet or make some changes Save the file open again Type incorrect password Error message displays: The file 'Test 2015 09 05 Test New.ods' is corrupt and therefore cannot be opened. LibreOffice can try to repair the file. The corruption could be the result of document manipulation or of structural document damage due to data transmission. We recommend that you do not trust the content of the repaired document. Execution of macros is disabled for this document. Should LibreOffice repair the file? YES OR NO DIALOG If YES nothing happens, leaving a “.~lock.2015 09 05 Test New.ods#” read only file. No correction is made. And LO closes. If NO Second message displays “The file '2015 09 05 Test New.ods' could not be repaired and therefore cannot be opened.” OK button. Third message “General Error” OK button. LO closes. I'm changing the subject from FILEOPEN to FILESAVE because the problem is when LO 4.4 saves the file, something is doing wrong, because, after saving, the problem is present. I noticed this since the release of the 4.4.0 in January 2015.
Created attachment 119050 [details] New Calc test file
Created attachment 119051 [details] screenshot LO 3.3
Created attachment 119052 [details] screenshot of error
Created attachment 119053 [details] screenshoot LO 4.1
Created attachment 119054 [details] screenshoot on linux
Created attachment 119055 [details] screenshot 2 on linux
Created attachment 119056 [details] screenshoot 3 on linux
Created attachment 119057 [details] screenshoot 4 on linux
Additional test. if the test file 2015 09 05 Test New.ods is saved to another file like 2015 09 05 Test New 2.ods and select all cells and erase all formats with Format - Clear direct formatting, then saving the file. The problem is not present. So I think that some of the formatting is has something to do with this issue.
Created attachment 119058 [details] Test file with no format On this file all the formatting was erased, then saved, and some little formattings were made.
(In reply to Robert Gonzalez MX from comment #5) > Steps to reproduce with LO 4.4.5 Repro. Let's mark as regression. I also tried with 4.3.0.1 and there was no corruption Win 7 Pro 64-bit, Version: 5.0.2.2 (x64) Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe Locale: fi-FI (fi_FI)
I reproduced it on Windows7-64bit (Libreoffice 4.4.5.2) But the file seems collectly saved on Ubuntu-15.04-x86_64 (4.4.2.2) I think it happens when the file contains a lot of data.
(In reply to yuri.musashi.miwa.tamura from comment #17) > I reproduced it on Windows7-64bit (Libreoffice 4.4.5.2) > > But the file seems collectly saved on Ubuntu-15.04-x86_64 (4.4.2.2) > > I think it happens when the file contains a lot of data. Which data, how much data, is to much ?
This seems to have begun at the below commit. Adding Cc: to Matúš Kukan ; Could you possibly take a look at this one? Thanks b89a610ba4db766795068aa7f5c93adc4e78eaeb is the first bad commit commit b89a610ba4db766795068aa7f5c93adc4e78eaeb Author: Matthew Francis <mjay.francis@gmail.com> Date: Sun Mar 15 05:57:15 2015 +0800 source-hash-fbf714b45625c50bb1c736ef231b5dbbab0016a1 commit fbf714b45625c50bb1c736ef231b5dbbab0016a1 Author: Matúš Kukan <matus.kukan@collabora.com> AuthorDate: Tue Oct 21 15:17:13 2014 +0200 Commit: Matúš Kukan <matus.kukan@collabora.com> CommitDate: Mon Nov 17 10:49:23 2014 +0100 package: Finally implement parallel zip entries deflating For that: 1, create ZipPackageStream::successfullyWritten to be called after the content is written 2, Do not take mutex when reading from WrapStreamForShare - threads should be using different streams anyway, but there is only one common mutex. :-/ Change-Id: I90303e49206b19454dd4141e24cc8be29c433045 :040000 040000 67383437fb16f4a24d936859ff4cdfa3a577ab76 9106ff29b6ddb6c66d9e2b516896e74c912cd27a M opt bibisect-44max$ git bisect log # bad: [cf6ea17155fabb2a120ba07c150735591ac861d7] source-hash-3f94c9e9ddfd807b449f3bb9b232cf2041fa12d2 # good: [fc71ac001f16209654d15ef8c1c4018aa55769f5] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e git bisect start 'latest' 'oldest' # good: [8cf60cc706948588e2f33a6d98b7c55d454e362a] source-hash-f340f0454627939f1830826fb5cc53a90e6c62a4 git bisect good 8cf60cc706948588e2f33a6d98b7c55d454e362a # good: [7beddf3808dadd525d7e55c00a5a90a2b44c23d3] source-hash-2f10386ce577f52e139aa23d41bc787d8e0b4d59 git bisect good 7beddf3808dadd525d7e55c00a5a90a2b44c23d3 # good: [fb3ec529b3f37f0c7eab2e9b7a9cc695c0f27676] source-hash-0516d123f53917d1833c7e8a8c528a619c71a0af git bisect good fb3ec529b3f37f0c7eab2e9b7a9cc695c0f27676 # good: [47a64818ddfe63bbb8e6448fcc476f55996d61b1] source-hash-d12efada389643ab0e13a280246d14caed273029 git bisect good 47a64818ddfe63bbb8e6448fcc476f55996d61b1 # bad: [8f2027699192b7f2aaf83f95a02c817f2e0c8d50] source-hash-eb6d27321d2d5f9d069c4a3cbcc9bc6e5b4c98ab git bisect bad 8f2027699192b7f2aaf83f95a02c817f2e0c8d50 # good: [5705bc95b469b4b7696309fba80ea590cabe8ff1] source-hash-90742105a5d95d175a89b5a253584fa1676ab02a git bisect good 5705bc95b469b4b7696309fba80ea590cabe8ff1 # good: [6022bfdffd46392ccd506f679d9b6605005c8b49] source-hash-a6e2e54c7e9ec5b852db3b3be578d79fda666601 git bisect good 6022bfdffd46392ccd506f679d9b6605005c8b49 # bad: [d06fd023188b2424a4954f522299ca5449bd7a64] source-hash-a42aa52acbbff738a00299de172ca85cb001d840 git bisect bad d06fd023188b2424a4954f522299ca5449bd7a64 # good: [220693b7b9b63600d402b3abe4862748b0b3ec2b] source-hash-e186db5257956a88ed5ed7a9db1867b44324252d git bisect good 220693b7b9b63600d402b3abe4862748b0b3ec2b # good: [e5388f18f8d7fd2d731a3f3ee8244065710f3395] source-hash-ad91cfdcf256f5af159f2f18d3b83f17b91849dc git bisect good e5388f18f8d7fd2d731a3f3ee8244065710f3395 # good: [99a6ccca1ee95f2561bc0085f3ce9d33bfa48672] source-hash-3e3b8483d7866e96bc75ddda283416c6829714af git bisect good 99a6ccca1ee95f2561bc0085f3ce9d33bfa48672 # good: [24db9952a5ed70772216b87b1a8d199f910881cc] source-hash-30f80f12fb1db4c9c6f19fcfda4e796891b6e03c git bisect good 24db9952a5ed70772216b87b1a8d199f910881cc # bad: [b89a610ba4db766795068aa7f5c93adc4e78eaeb] source-hash-fbf714b45625c50bb1c736ef231b5dbbab0016a1 git bisect bad b89a610ba4db766795068aa7f5c93adc4e78eaeb # good: [32815bb3ab0a9dd2b4c2b7e800103d4c1537b7a1] source-hash-db5552631b13e5a1d330929cd5093bd0f9894ec8 git bisect good 32815bb3ab0a9dd2b4c2b7e800103d4c1537b7a1 # first bad commit: [b89a610ba4db766795068aa7f5c93adc4e78eaeb] source-hash-fbf714b45625c50bb1c736ef231b5dbbab0016a1
Matúš Kukan committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=eaed822c9cf6b3762f727f1281003dafd300df6d tdf#89236: Don't deflate encrypted document in parallel It will be available in 5.2.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.
Thanks for bisecting & letting me know. That's awesome! It's fixed in master and pending reviews in gerrit: https://gerrit.libreoffice.org/#/c/21241/ for 5-1 https://gerrit.libreoffice.org/#/c/21242/ for 5-0
Matúš Kukan committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=57ee45cd6b7655bbd04972287802fcf300e1a933&h=libreoffice-5-1 tdf#89236: Don't deflate encrypted document in parallel It will be available in 5.1.0.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.
Matúš Kukan committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fe7d69565866b4b02cde5aebdab4cbc11d00af2b&h=libreoffice-5-0 tdf#89236: Don't deflate encrypted document in parallel It will be available in 5.0.5. 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.
*** Bug 96261 has been marked as a duplicate of this bug. ***