Description: (I started writing about this in bug 161858, but since it looked as a separate bug, I am filing it here.) LO crashes recently, with languagetool activated or not. Files are sometimes described as being corrupt, but recovered anyway and the user is propted to save them somewhere. But the original is ok and not corrupt. So this creates confusion as to which file can be trusted as being the one with the last corrections and stable, but also the windows prompting the user to recover the files are not clear. Steps to Reproduce: 1. The firs thing would be to make LO crash. In my setting I simply have the two attached files open with Languagetool activated as described in bug 161858, but I am told that not everybody's LO crashes. 2. Follow the instructions after crash to recover all documents and save the corrupted one (as prompted) in a folder, I am including snapshots Actual Results: There are several issues here. 1. The document should not be corrupted in teh first place, but I am told it is 2. In the procedure I am told that it cannot be repaired and not be opened 3. In another window I am told that it was indeed recovered: it says Original document recovered with an orange "V" instead of a green one and simply "Successfully recovered". What is the meaning of the different colours (for the Vs, I also saw a red one once) and explanations? Why does it warn you that it cannot be repaired in one window and that it is recovered in the next? Why does it prompt you to save it in the last step, but opens the original one after that? I thought that the "safe" one was the one I saved, but discovered (so it seems) that the one LO re-opens in its current location (we are useing Gdrive to share documents, so it is crucial for versioning and sharing that we keep documents there), where it is perfectly functioning. Expected Results: There should be no crash and no corruption and no contradiction in the recovery windows, and no saving of the "corrupted" file since it is confusing for the user, or else one should explain better the meaning of the steps. Reproducible: Always User Profile Reset: No Additional Info: Version: 24.2.5.2 (X86_64) / LibreOffice Community Build ID: bffef4ea93e59bebbeaf7f431bb02b1a39ee8a59 CPU threads: 8; OS: macOS 14.5; UI render: Skia/Metal; VCL: osx Locale: en-US (en.UTF-8); UI: en-US Calc: threaded
Created attachment 195421 [details] file corrupt
Created attachment 195422 [details] File corrupt cannot be opened
Created attachment 195423 [details] Original document recovered
Created attachment 195424 [details] save recovered odt to a folder
Created attachment 195425 [details] smaller file
Created attachment 195426 [details] bigger file
Thnak you for reporting the bug. You refer to bug 161858, that isn't fixed in version 24.2.5.2. So could you please retest with 24.2.6 (when it is released) or 24.8.0? I've tested with 24.8.0 (Windows 10) and could open attachment 195426 [details] without any problem and without a crash. => NEEDINFO
Hi, I tested the aforementioned file with the version below and it did not crash. Will this test do? thanks, D. Version: 25.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: a7de9cc5e89cd0d0c2f6363b2c0cc265c528b121 CPU threads: 8; OS: macOS 14.6.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en.UTF-8); UI: en-US Calc: threaded
[Automated Action] NeedInfo-To-Unconfirmed