I'm running a new daily build (after a while only running releases). The last exit from the app may have been a crash, causing writer to want to try offer to restore documents. Some of those documents still exist, some do not. In particular, a document named /tmp/a01.odt no longer exists. Now, I get the following log message: warn:sfx:8143:8143:sfx2/source/control/recentdocsview.cxx:90: caught exception trying to find out if doc <file:///tmp/a01.odt> is encrypted: com.sun.star.ucb.InteractiveAugmentedIOException message: an error occurred during file opening Code: 22 this shouldn't happen, because LO should first figure out whether a file even exists before trying to check whether it's encrypted. Even if, somehow, this check were allowed to assume the file exists generally (which again IMHO it shouldn't), then certainly that should not be the case for a file in the temporary directory, after a significant amount of time in which the app has not run, when it is now coming up again.
Build info: Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: c1659be6ff0e0c91e0c7d1e6acb6ab18821e2bf7 CPU threads: 4; OS: Linux 5.9; UI render: default; VCL: gtk3 Locale: en-US (en_IL); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-03-02_06:18:34
Update: I get this kind of messages even after after opening and closing LibreOffice a few times - with none of the files having been loaded. So there's not even a legitimate document recovery interest.
*** This bug has been marked as a duplicate of bug 131850 ***
Please don't close bugs which aren't identical dupes without discussion with the bug poster. This bug is not about a crash or a hang.
(In reply to Eyal Rozenberg from comment #4) But this bug is about what the code does when showing recent files. I just happen to know what you see. So please don't insist on "discussing something", when the closing itself was a pointer to "that bug discusses why some code tries to read encrypted state of files shown "recent" screen".
(In reply to Mike Kaganski from comment #5) > But this bug is about what the code does when showing recent files. I just > happen to know what you see. So please don't insist on "discussing > something", when the closing itself was a pointer to "that bug discusses why > some code tries to read encrypted state of files shown "recent" screen". Even if I accepted your reasoning 100%, you didn't even bother to state it when closing. Also - I don't. That is, I believe a dependent bug is a better fit. In the literal sense, it is not the same problem even if the same code is reponsible. Also, it is theoretically possible that the other bug is fixed without a proper fix for this bug.
(In reply to Eyal Rozenberg from comment #6) Whatever. If you prefer "I have this unique bug that I filed myself, don't touch it" over "let's mark it duplicate of another bug, which is the same problematic code, where the reason is identified, the person who did that is known, and increasing dupe count would mark that one more important to maybe persuade that person to fix that", it's up to you.
(In reply to Mike Kaganski from comment #7) > Whatever. If you prefer "I have this unique bug that I filed myself, don't > touch it" over "let's mark it duplicate of another bug, which is the same > problematic code, where the reason is identified, the person who did that is > known, and increasing dupe count would mark that one more important to maybe > persuade that person to fix that", it's up to you. With respect - there are three problems with your argumentation. 1. When a bug is not a perfect dupe - you still need to discuss closing a bug with someone, even if you believe they should obviously prefer this possibility. Both because they might surprise you with additional information and a s matter of courtesy. 2. Utilitarian motivation. The question is what the truth is about the relation between the bugs, more than what might be end up being more expedient for me. 3. You've presented a false dichotomy. I prefer "let's mark it a dependent of another bug" - which does about the same to convince the relevant person to fix the other bug IIANM.
(In reply to Eyal Rozenberg from comment #4) > Please don't close bugs which aren't identical dupes without discussion with > the bug poster. This bug is not about a crash or a hang. Mike fixed bug 131850 by removing the encryption check. So this duplicate is fixed as well.