As documents that are opened read-only can not be modified anyway, we should turn off automatic saving for recovery for these documents. Saving empty files for recovery is similarly useless and should be turned off too.
Does this help for recovery purposes? IE. is something saved in /tmp even if read only?
I'm going to assume that there is a reason for doing this. Especially for empty documents, that seems to make perfect sense. Marking as NEW and leaving it up to you guys (Developers) to decide how to implement :) Marking as LOW as it's not going to add a lot for the end user, just a functional addition for "behind the scenes" stuff.
Sorry for my irresponsiveness. First, a clarification: Read-only files can now (3.6+) be edited. Thus, among read-only files, the non-saving behaviour should only apply to unmodified read-only files (as received via email, etc.). Rationale for this change: When LibO crashes and users have accidentally or deliberately opened any of these types of documents, LibO will try to restore them – this is useless (obviously, since there is nothing to restore). It also adds to the many windows that restoration wizard tends to open, therefore can be confusing to users. Lastly, it is also rather disappointing when a file is restored and there is no content in it at all. Marking medium (again?), because it does have user impact.
I've sort of accepted (or tolerated with) this behaviour, but I must say that it makes LibO seem rather unpolished. In that sense too there is an impact. So, it would be a good idea to (carefully) resolve this.
Read only files cannot be edited - an example: just go to https://bugs.freedesktop.org/show_bug.cgi?id=37256, do not download but instead just directly open in LibreOffice version 4, this is technically a read only file now (as it hasn't been saved) but you cannot edit it. Multiple people complaining about this :-/ Just my two cents, as this is already NEW, moving on to more triaging :)
(In reply to Stefan Knorr (astron) from comment #3) > First, a clarification: Read-only files can now (3.6+) be edited. Thus, > among read-only files, the non-saving behaviour should only apply to > unmodified read-only files (as received via email, etc.). Would it be better to say "Don't save doc recovery info for unmodified file"?
*** Bug 131734 has been marked as a duplicate of this bug. ***
*** Bug 85687 has been marked as a duplicate of this bug. ***
*** Bug 153137 has been marked as a duplicate of this bug. ***
*** Bug 137879 has been marked as a duplicate of this bug. ***
Bug 137879 asks for the same thing, but for temporary files - which may not be empty nor read-only. Should we unify the two bugs (expanding the scope of this one and marking bug 137879 as a dupe), or keep them separate?
Just to note that there are readonly docs that can be form-filled. So unless it is OS-marked as R/O, it gets rather complicated.
I can also get the document recovery dialog after killing OOo 3.3 with a read-only file opened, so marking as inherited.
proposed fix at https://gerrit.libreoffice.org/c/core/+/154490
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d16d86685afdf3d321cc282a39a65f38381b6eaa tdf#57414 autorecovery: if no recovery doc, remove from RecoveryList It will be available in 24.2.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/db9fa6da9d57853e0089a063ec372e11ce6046a9 related tdf#57414 autosave: try harder to know when !IsModified It will be available in 24.2.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9e0f13b2c4d31537162434b5b932b265c62349e0 tdf#57414 autorecovery: don't always add every file to RecoveryList It will be available in 24.2.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9fffac201136dc4f0a128171c17b0fd38836c043 tdf#57414 autorecovery: not in RecoveryList? always delete tmp files It will be available in 24.2.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f5d6888bd1b945596684cb643118e0e07477d3fa tdf#57414 autorecovery: don't store unmodified docs in RecoveryList It will be available in 24.2.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/63bb760acc8aa50c352f3349e8adf3db381b4911 tdf#57414 autorecovery: avoid unnecessary storeToRecoveryFile It will be available in 24.2.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ceeb48b33b374dfcd970d4fdd194ce0301bbb65a tdf#57414 autorecovery: ignoreClosing during Emergency/SessionSave It will be available in 24.2.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.
There are three types of Recovery. One is emergencySave (an exception in the program triggers a save-and-restart), another is SessionSave (when the OS shuts down), and the third is a timed autoRecovery. In the case of EmergencySave and SessionSave, the intent is to recover the working environment, so ALL documents are attempted to be recovered. (The patches do a bit of work to ensure that happens better). In the most general case - which OP is likely to referring to - the patches only try to recover modified documents that have a recovery file. I think this bug is fixed.
*** Bug 148438 has been marked as a duplicate of this bug. ***