Hello Platform: Windows 7 64bits Version: 4.1.0.0.beta2 Build ID: 33224f4f11a05cfad2249e812fcc2975fbb61f6 I did not select the version because not included in the list at this time. Steps to reproduce 1. Check Tools> Options> Load/Save> General> Save AutoRecovery information every 1minutes (or another short delay) 2. Check Automatically save the document too 3. Open a document and edit it 4. File> New> Text 5. Type something (test for example) 6. Wait for the autoRecovery save. when the specified time has elapsed, AutoRecovery is executed but modified documents are not saved and Save Icon (standard toolbar) and Modified status (status bar) still enabled. Regards Pierre-Yves
Reproducible Win7x64Ult. Version: 4.1.0.0.beta2 Build ID: 33224f4f11a05cfad2249e812fcc2975fbb61f6
Hello Pierre-Yves, I get the save with modified document on master LO 4.2.0.0.alpha0+ Build ID: 3e6853ae3e093b919ff3732e8fac05cb0a0fba5 & Windows 7 Home Premium. Jacques Guileron
*** Bug 66902 has been marked as a duplicate of this bug. ***
*** Bug 66190 has been marked as a duplicate of this bug. ***
In my case LO 4.2.0.2 Kubuntu 13.10 amd64 Even if autorecovery 5 min, automatically save doc. too, always create backup - after 120 min there is just only the latest manually saved version a version saved manually before 1. This situation tend to make user who belies in LO quiet but leaving him in danger of big disaster. That's why I increase the classification to critical (I tend to feel it as blocker, but) 2. In combination with "always create backup copy" which makes the user fell even more secure actually does opposite. Every manually save means loose the previous backup. 3. In combination with strange autorecovery behaviour, when after autorecovery the user get even older version, than the last manually saved makes LO almost unusable for serious work. (I'm not sure, if this is a separate bug or not - if yes, I can create it) From my point of view, the autorecovery function in broader point of view or "user work securing functionality" should be change/fix as complex. The user should be at least before agreeing with autorecovery, provided with information what is he/she doing, i.e. what autorecovery and backup (at least here should be a link to backup file) is here at disposal. Otherwise the user multiply the range of disaster.
My findings: This was never implemented right - it's not a regression, simply bad implementation somewhere in the 4.1 series. As for the priority - I'm changing it for a couple reasons: 1) Clearly not affecting a ton of people, a couple dupes over two years; 2) You're not going to lose any data unless you specifically say "no" to saving when you try to close - if LibrOffice crashes, your auto recovery works fine 3) This was a *new* feature in 4.1 - worst case we should just remove it as it never worked right (something I'll probably do just to avoid confusion) That being said: Major - can result in loss of data if a user deliberately chooses not to save manually when the save prompt comes on; High - default for major issues, seems appropriate.
I pushed a patch to hide the option entirely considering it's never worked properly.
(In reply to Joel Madero from comment #7) > I pushed a patch to hide the option entirely considering it's never worked > properly. Ok, thank you Joel. Therefore, can we close this bug? Regards Pierre-Yves
I think not only make it invisible, but also set up to false, to avoid it working from an updated profile.
Joel committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4653c91a89cfe802754377bcdafc291526254a03 tdf#65509 - Auto Save Also Too Disabled It will be available in 5.0.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.
*** Bug 94706 has been marked as a duplicate of this bug. ***
Have another aspect to this in that while suppressed from .UI as in comment 10, it remains available from Expert Configuration where a search for AutoSave returns confusing options.
Created attachment 119311 [details] ExpertConfig search for AutoSave in 5.0.2.2
Autosave doesn't appear to be working for me in 5.0.2.2.
It seems like auto save not working at all is a separate issue from this one. Should be reported separately. Thanks
Migrating Whiteboard tags to Keywords: (implementationError)
*** Bug 76950 has been marked as a duplicate of this bug. ***
In bug 76950 I described the same bug. To my opinion the option works but you have to close and restart again LibreOffice after changing the option. But the question still is: Shall the current solution (hide option) be maintained or shall the bug fixed sometimes in future? In the first case this bug should be closed.
*** Bug 97540 has been marked as a duplicate of this bug. ***
I just realised that the feature is missing. This cost me some data, sadly, because the "normal" AutoRecovery didn't work after a blue screen produced by windows... The AutoRecovery-Program told me that the data couldn't be found. I would prefer that the option to save the document will be implemented again. Now I use the ExpertConfig-settings. By the way - thank you for working on this really fine piece of software!
This should likely be an easy fix as all that is needed is to check whether the checkbox is enabled and if so, execute the .uno:Save command.
> In bug 76950 I described the same bug. To my opinion the option works but > you have to close and restart again LibreOffice after changing the option. So that is a different issue - anyway now that this issue evolved in changing the UI position of AutoSave. IMO reopening bug 76950 is a good thing. (The topic that a restart is needed comes up more frequent. When changing a the language for UI, a message is shown. For changing OpenGL option, the UI shows it in the dialog.. )
(In reply to V Stuart Foote from comment #13) > Created attachment 119311 [details] > ExpertConfig search for AutoSave in 5.0.2.2 When was that changed/implemented? (And did that change turn it on by default?)
I just had a colleague loosing his work. He had created a document and started working in it. He never saved it in between. When he was typing he used some keyboard shortcuts and inadvertently closed the document. He's not sure what exactly happened, since it all went really fast. However the end result was that it did not get stored on disk. I'm not sure if there is solution for these kind of stupidities, but I think it happens quite often in real life situations. It happens to me once or twice a year, although I know I should always start a new document and save it immediately *and* use CTRL-S to save on a regular interval. However the end result is that I don't trust my text editing program from saving me from these kind of stupidities. This probably needs to end up in some kind of feature request, but I really wanted to share it in this bug, so brighter minds can think about a solution that works for users. Maybe always keep a copy of the last 10 documents in a temp directory or something? And save them in 10 minute intervals even when a user says not to save?
Hi Patrick, (In reply to Patrick Smits from comment #24) > I'm not sure if there is solution for these kind of stupidities, .... Yes, do it often enough so that you do it less in the future ;) (Helps for me anyway...) > twice a year, although I know I should always start a new document and save > it immediately *and* use CTRL-S to save on a regular interval. However the Once saved once, autoRecovery works pretty well. If not, it's a gamble. > This probably needs to end up in some kind of feature request, but I really > wanted to share it in this bug,... Better to bring it to a new report (if not covered by an existing one) and assign to libreoffice-ux-advise@lists.freedesktop.org, Thanks, Cor
(In reply to Patrick Smits from comment #24) > I just had a colleague loosing his work. He had created a document and > started working in it. He never saved it in between. When he was typing he > used some keyboard shortcuts and inadvertently closed the document. He's not > sure what exactly happened, since it all went really fast. However the end > result was that it did not get stored on disk. Yes that is unfortunate. > I'm not sure if there is solution for these kind of stupidities, but I think > it happens quite often in real life situations. It happens to me once or > twice a year, although I know I should always start a new document and save > it immediately *and* use CTRL-S to save on a regular interval. However the > end result is that I don't trust my text editing program from saving me from > these kind of stupidities. Yes a solution would be to keep copies of autorecovery saved documents, even when a user has stated not to save it. This was mentioned in bug 94042.
(In reply to Cor Nouws from comment #22) > > In bug 76950 I described the same bug. To my opinion the option works but > > you have to close and restart again LibreOffice after changing the option. > > So that is a different issue - anyway now that this issue evolved in > changing the UI position of AutoSave. > IMO reopening bug 76950 is a good thing. > Sorry Cor, I don't agree in this case. If you go on the test procedure of the original description with: 6. .. 7. Close LibreOffice without saving both files. 8. Restart LibreOffice. 9. Open the document of step 3 and edit it 10. File> New> Text 11. Type something (test for example) 12. Wait for the autoRecovery save. 13. Check the time stamp of the opened document. It has been changed. Hence now autorecovery works correctly at least for existing documents. But it does not work with new documents. I did not found a saved version of the new file, neither in the 'My Documents' folder, nor in the Backup folder and also not in the folder of the already existing document. Tested with version 4.4.7 and Win7.
This is still broken for me on version 4.3.3.2 in debian and version 4.3.7.2 in windows. I have lost half a days work MULTIPLE TIMES. I'm not sure if this report is saying now that it's been fixed or if the autosave feature has been REMOVED? I'm wondering if i'll gain anything by upgrading to the latest version--since I cannot reliably reproduce the bug, the only way to confirm is to see if I lose more swathes of work. I uploaded a question to stackexchange on it since I thought it was a user error at first. http://tinyurl.com/huogel3 As you can see, it sometimes does observe the autosave settings, and sometimes doesn't. I do not know what the conditions are, but right now I have an instance of libreoffice calc open and I type in changes and hit enter, and nothing in the main or backup directory gets updated within the configured timeframe. Earlier today when I did the same test, it updated just fine! > As for the priority - I'm changing it for a couple reasons: > 1) Clearly not affecting a ton of people, a couple dupes over two years; A serious bug felt by one or two people is still a serious bug. I also don't think this is a reliable indicator of how many people are running into it. That assumes the people who experience it are all filing reports. > 2) You're not going to lose any data unless you specifically say "no" to saving when you try to close - if LibrOffice crashes, your auto recovery works fine Who said auto recovery works fine? The autosaves aren't happening which means the backups to the backup directory aren't being saved to recover from it (that's where autorecovery gets it, right?). And I've lost tons of progress after autorecovery. I don't even understand how autorecovery works--even if I try to cancel my way past it it offers to save a backup. It's not intuitive. Not to mention, on multiple occasions the app hasn't closed cleanly. My PC never crashes yet the amount of times I've seen autorecovery pop up is ridiculous. > 3) This was a *new* feature in 4.1 - worst case we should just remove it as it never worked right (something I'll probably do just to avoid confusion) Just to clarify, you're proposing to remove an elementary feature like autosaving of documents that most people would naturally assume to exist in any modern office application?
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
still not working in Version: 6.2.0.0.alpha0+ Build ID: 3208fcb3a36d75d6290d9c548430682f153b09db CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-09-20_23:54:32 Locale: nl-NL (nl_NL.UTF-8); Calc: threaded
as per comment: "this never worked correctly" and duplicate in 3.5.x > old bug.
sorry, I'm confused about earlier versions, when it was implemented. Setting version to unspecified.
--- Summary of this bug report --- The option “Automatically save the document too” was introduced in version 4.1.0 and was hidden in version 5.0.0 (see comment 10). Option is still available with the Expert Configuration. Function according to help (version 6.1.x): Specifies that LibreOffice saves all open documents when saving auto recovery information. Uses the same time interval as AutoRecovery does. Additional information: If both options “Always create backup copy” and “Automatically save the document too” are enabled, also the backup copy is updated with the current version of the document in the user defined interval. A backup of the state, when a document has been opened, does not exist in this case. There are 2 cases, where the option “Automatically save the document too” is useful: [1] If LibreOffice crashes and afterwards a recovery is not performed or is not successful. In this case you can just open the respective document and will get the document in the state at the time of the last automatic save. [2] If a user accidentally closes a changed document without saving. Also in this case you get the document in the state at the time of the last automatic save. But the option “Automatically save the document too” does not work as expected in some cases: (1) After enabling the option “Automatically save the document too” LibreOffice has to be closed and restarted again thereby the option becomes effective (see comment 1 and comment 27). (2) New documents that have not been saved by the user at least once, are not saved automatically (see comment 27). (3) According bug 66902 (comment 3) with Linux LibreOffice crashes if the option is enabled. These problems should be fixed, before the option becomes visible again. And a proposal, that should be considered during fixing this bug: The option “Automatically save the document too” only works if the option “Save AutoRecovery information“ is enabled. For a user I think it would be more understandable if both options can be changed independently. In this case you need an additional time interval for the option “Automatically save the document too”.
*** Bug 123424 has been marked as a duplicate of this bug. ***
I'm one of the 'tiny number' of people who have reported this problem. I can't follow all of the comments here, but it seems there are voices calling for hiding it rather than fixing it. If so, let me weigh in. I discovered OpenSource software a couple of decades ago, and have become an avid advocate and implementer, in my life, my blogging, my research, my book writing, my professional work, and my civic activism. I am working on a book talking about how important and revolutionary OpenSource is, and (I hope) pointing the way for some critical contributions the community could make. But OpenSource, like any software, isn't perfect. My machine and various software crash from time to time; there are websites and files that won't work in OpenSource platforms; updates, fixes, and improvements often aren't easy; add-ons that I have become dependent upon aren't updated, and I lose important functionality when I upgrade. Nevertheless, I stay with you guys and gals because I am convinced that your work is essential (and not to wade into politics, but this is particularly true now, with kleptoplutocrats grabbing control everywhere). However, when I'm working and my stuff crashes, and autosave isn't effective, I'm totally screwed. Hours of work disappear. The one poster is right: perhaps only a few people are complaining, but that's an inadequate metric. "96% of unhappy customers don’t complain, however 91% of those will simply leave and never come back." https://beyondphilosophy.com/15-statistics-that-should-change-the-business-world-but-havent/ There are problems with all software. But I have never spent as much time complaining as I am now, because for me, systems that crash without an autosave aren't annoying. They're toxic. And to my mind, ignoring such a large problem contradicts the culture and commitment of OpenSource.
OK, it happened again. Because there is no resolution for this problem, I have been automatically hitting Save on a regular base. But, as sure as God made little green apples, the very first time I am tired and I forget to do it regularly, the system crashes. It happened this morning, lost a good half-hour of work. You cannot be proud of this. And FWIW, I initially submitted this bug with another problem I am having with Copy & Past. The two were separated. You may wish to consider them together, because this AM the system crashed when C&P acted weirdly and I tried to correct it. I can't be sure, but these seem to have happened in tandem before. Problem: I copy, paste and one of two things frequently happens: 1) The *previous* copy (the one before the current one) is pasted instead, and the most recent Copy -- or sometimes Cut -- is gone. Fortunately, I can recover with Ctrl Z. 2) I go to paste, often Ctrl Shift P for an unformatted text paste, and the system pastes a .bmp, and 'unformatted text' simply isn't available in the options. That's what happened this time; when I went to correct the .bmp, the system crashed.
*** Bug 127224 has been marked as a duplicate of this bug. ***
(In reply to Harald Koester from comment #33) > --- Summary of this bug report --- > > The option “Automatically save the document too” was introduced in version > 4.1.0 and was hidden in version 5.0.0 (see comment 10). Option is still > available with the Expert Configuration. Can't find that option. I've searched in expert configuration and with enabling experimental features.
(In reply to Dieter from comment #38) > Can't find that option. I've searched in expert configuration and with > enabling experimental features. It should be there as shown in attachment 119311 [details].
(In reply to Aron Budea from comment #39) > (In reply to Dieter from comment #38) > > Can't find that option. I've searched in expert configuration and with > > enabling experimental features. > It should be there as shown in attachment 119311 [details]. Thank you. It works.
Explaining the meaning of attachment 119311 [details] ExpertConfig search for AutoSave AutoSave: corresponds to Options - Load/Save - Save Autorecovery information AutoSaveTimeInterval: every x minutes AutoSavePrompt - ??? UserAutoSaveEnabled: corresponds to Options - Load/Save - Automatically save the document too. (visible False - see commit 10 patch). In the current implementation, "user auto save" is completely dependent on "recovery auto save". Separating the two would not be easy. (Things like impress slide-show temporarily disable autosave/autorecovery, and things like --headless need to prevent both altogether. > (1) After enabling the option “Automatically save the document too” > LibreOffice has to be closed and restarted again A dialog warns about this now, so not a big deal. > (2) New documents that have not been saved by the user at least once, > are not saved automatically Not surprising. What name would you give it? Where would you save it? I guess that is where it would need to pop up a save-as dialog. But this entire thing seems SUPER FRAGILE. In debugging this, I frequently had to delete the user profile in order to have the autorecovery subsystem start up at all. After two or three option modifications, it would be messed up somehow.
*** Bug 142175 has been marked as a duplicate of this bug. ***
*** Bug 154843 has been marked as a duplicate of this bug. ***
(In reply to Justin L from comment #41) > > (1) After enabling the option “Automatically save the document too” > > LibreOffice has to be closed and restarted again > A dialog warns about this now, so not a big deal. Since LO 7.4.0, thanks to commit 18cc891483fef63ad168273658a30bff72b87a95 Author: Tünde Tóth on Tue May 31 16:11:03 2022 +0200 tdf#149401 show "Restart LibreOffice" dialog changing AutoRecovery
(In reply to Justin L from comment #41) > > (2) New documents that have not been saved by the user at least once, > > are not saved automatically In 24.2 I see an AutoSave alternating between instdir/user/backup/untitled_0.odt and untitled_1.odt. So I think this "blocker" is no longer relevant.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d36ae6786e05deda7e78338d36624af371e7a3ed tdf#65509 apply new AutoRecovery timeInterval without restarting 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.
In general, UserAutoSave seems to be working: -I open an existing file and make a change. After the idle timeout my document is updated and the "modified document" indicator on the save button goes away. -I create a new document and make some changes without saving the document. After the idle timeout, the backup folder contains an AutoSave named untitled_0.odt. -I manually save and give a name to the file now. (untitled_0.odt is removed) -make a change. After the idle timeout, my document is updated. So in general the "automatically save my document" function seems to work as expected. So I think I'll show the option again in the GUI (which will instruct the user to reboot after changing it) and keep testing to find edge cases that fail.
*** Bug 96851 has been marked as a duplicate of this bug. ***
I reviewed the duplicate and see-also reports. I don't find any reason in them to not move ahead. https://gerrit.libreoffice.org/c/core/+/154389
Perhaps worth noting: AutoSave and Backup have no folder hierarchy, so editing multiple files with the same name (from different folders/sources) means the last one wins. (I don't have a problem with this - an archive versioning enhancement would be needed to deal with situations like these. But quite honestly I find this far beyond the scope of an office suite - that should be the function of dedicated backup/syncing tools.)
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5eae366cbdfb4c2e9f7a9b88257d12c400831456 tdf#65509 - re-make visible userautosave config option 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.
(In reply to Justin L from comment #41) > (Things like impress slide-show temporarily disable autosave/autorecovery, > and things like --headless need to prevent both altogether.) The code doing this in impress is sd/source/ui/slideshow/slideshowimpl.cxx if( ANIMATIONMODE_SHOW == meAnimationMode ) ... setAutoSaveState( false ); In unit tests, this was used by framework/qa/complex/framework/autosave/AutoSave.java: aConfig.writeRelativeKey("AutoSave", "TimeIntervall", Integer.valueOf(1)); This is the only instance I found where the actual time interval is changed I didn't find anything related to --headless specifically. I didn't really fix anything, so I could mark it as WORKSFORME, but since I reverted comment 10's patch, I'll mark it as fixed.
(In reply to Justin L from comment #41) > But this entire thing seems SUPER FRAGILE. In debugging this, I frequently > had to delete the user profile in order to have the autorecovery subsystem > start up at all. This is probably only a development build problem. The recovery is disabled by: instsetoo_native/ooenv export OOO_DISABLE_RECOVERY=1 which needs to be commented out (a 0 or "" is not good enough - it can't exist) bool const bDisableRecovery = getenv("OOO_DISABLE_RECOVERY") != nullptr Basically, if there was any recovery information, then autosave doesn't start up for the developer - who has no indication that recovery info even exists.
(In reply to Justin L from comment #41) > AutoSave: corresponds to Options - Load/Save - Save Autorecovery information > AutoSaveTimeInterval: every x minutes Note that these were actually an error, that was fixed for bug 156308. The proper settings (for 24.2+ and prior to 2021-ish) are Recovery/AutoSave/Enabled and Recovery/AutoSave/TimeIntervall.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/97e5f7be679c9cc34d905987d08b62a67dde022c tdf#65509 autosave: apply UserAutoSave without restarting 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.
I'm testing something else in 24.2.0 Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 24d0a62bd75b9a895c419aa165da648ab18f134d CPU threads: 8; OS: Linux 5.18; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded I have set Autosave interval to 10 minutes and also turned on "Automatically save a copy of the document too". Is the auto save data stored in ~/.config/libreoffice/4/user/backup/ ? If so, I note that although the modification time on that directory is 17:32 today (about the time I started Writer), there are no files in there. I have Always create backup copy enabled, and I have manually saved the file - does that option mean a backup copy should be saved somewhere? If so, it's not in the above backup area. I also noticed terminal window output that might be related, which appeared as the autosave occurred: warn:legacy.osl:422367:422367:xmloff/source/text/txtparae.cxx:389: hyperlink without a URL --> no export to ODF warn:legacy.osl:422367:422367:xmloff/source/text/txtparae.cxx:389: hyperlink without a URL --> no export to ODF warn:legacy.osl:422367:422367:xmloff/source/text/txtparae.cxx:389: hyperlink without a URL --> no export to ODF warn:xmloff:422367:422367:xmloff/source/text/XMLTextNumRuleInfo.cxx:89: <XMLTextNumRuleInfo::Set(..)> - numbering rules instance does not contain any numbering rule warn:legacy.osl:422367:422367:xmloff/source/text/txtparae.cxx:389: hyperlink without a URL --> no export to ODF warn:legacy.osl:422367:422367:xmloff/source/text/txtparae.cxx:389: hyperlink without a URL --> no export to ODF warn:legacy.osl:422367:422367:xmloff/source/text/txtparae.cxx:389: hyperlink without a URL --> no export to ODF warn:legacy.osl:422367:422367:xmloff/source/text/txtparae.cxx:389: hyperlink without a URL --> no export to ODF warn:legacy.osl:422367:422367:xmloff/source/text/txtparae.cxx:389: hyperlink without a URL --> no export to ODF warn:legacy.osl:422367:422367:xmloff/source/text/txtparae.cxx:389: hyperlink without a URL --> no export to ODF warn:xmloff:422367:422367:xmloff/source/text/XMLTextNumRuleInfo.cxx:89: <XMLTextNumRuleInfo::Set(..)> - numbering rules instance does not contain any numbering rule warn:legacy.osl:422367:422367:xmloff/source/text/txtparae.cxx:389: hyperlink without a URL --> no export to ODF warn:legacy.osl:422367:422367:xmloff/source/text/txtparae.cxx:389: hyperlink without a URL --> no export to ODF warn:legacy.osl:422367:422367:xmloff/source/text/txtparae.cxx:389: hyperlink without a URL --> no export to ODF (I found this bug report because I was trying to find out what "Automatically save a copy of the document too" means, and also why it's needed if Writer's basic autosave feature works. (I still have little idea on either aspect.) I made a change, waited for auto save, and killed Writer, and restarted it, and I'm happy to say the changes were indeed recovered. But I couldn't find a backup copy of my document in that config backup directory nor in the current directory I started it from, where the file is. Certainly the info in the help link (see below: it says a .bak file is created), is wrong. Finally, I note that https://help.libreoffice.org/24.2/en-US/text/shared/optionen/01010200.html?&DbPAR=WRITER&System=UNIX doesn't answer these questions either, and the panel described is quite different to what's in 24.2.0. Hope this info is of some value.
(In reply to Luke Kendall from comment #56) > Is the auto save data stored in ~/.config/libreoffice/4/user/backup/ ? Yes. > If so, I note that although the modification time on that directory is 17:32 > today (about the time I started Writer), there are no files in there. That is expected when you manually save a document. The recovery files (<filename>_x.odt) are removed on a manual (or automatic) save (since they are now obsolete as the saved document is more up-to-date than the recovery files). > I have Always create backup copy enabled, and I have manually saved the file > - does that option mean a backup copy should be saved somewhere? Yes. You should have a <filename.ext>.bak file in that folder UNLESS you also enabled the "Place backup in same folder as document" sub-option. (Of course, these previous versions cannot happen on the FIRST save of a new document.) Also note that they only happen when the document itself is updated, not when an AutoRecovery file is made. That is why "backup copy" is not a sub-option under the AutoRecovery timer. > warn:legacy.osl:422367:422367:xmloff/source/text/txtparae.cxx:389: hyperlink > without a URL --> no export to ODF The comment here says // hyperlink without a URL does not make sense I'm sure this (and the other provided errors) are irrelevant for creating the .bak file. It is basically just a file-move. > (I found this bug report because I was trying to find out what > "Automatically save a copy of the document too" means, and also why it's > needed if Writer's basic autosave feature works. That option doesn't exist. It is either "Automatically save the document too" or "Always create backup copy". "Automatically save the document" (aka UserAutoSave) means just that - there is no need to manually save because the document is saved every x minutes. "Always create backup copy" (aka CreateBackup) basically means "when re-saving a document, instead of deleting filename.ext before creating an updated version, move that previous version to filename.ext.bak". "Automatically save the document" effectively disables the autorecovery, since the <filename>_x.odt files are removed after a successful save. This option is obviously much more dangerous than autorecovery since the document itself is modified. IMHO, this should never be enabled without having a separate backup system saving previous versions. It is primarily needed for LibreOfficeKit/Online where the document is expected to be automatically updated, and where the underlying file system takes frequent snapshots. > I made a change, waited for auto save, and killed Writer, and restarted it, > and I'm happy to say the changes were indeed recovered. But I couldn't find > a backup copy of my document in that config backup directory nor in the > current directory I started it from, where the file is. I think you are making a mistake in equating "AutoRecovery" with "UserAutoSave". AutoRecovery creates a recovery file automatically (without making any changes to your actual document), while "Automatically save the document too" updates the actual document (removing the recovery files when successful). The .bak file is only created when the actual document is updated, not when a recovery file is updated.
(In reply to Justin L from comment #57) > "Automatically save the document" effectively disables the autorecovery, > since the <filename>_x.odt files are removed after a successful save. This is incorrect. implts_saveOneDoc first does Reference< XStorable > xDocSave if (m_eJob & Job::UserAutoSave) and after that it does a xDocRecover->storeToRecoveryFile to rInfo.NewTempURL So, while xDocSave does remove the old recovery files, a new one is created immediately afterwards. // If userautosave is enabled, first try to save the original file. // Note that we must do it *before* calling storeToRecoveryFile, // so in case of failure here we won't remain with the modified flag // set to true, even though the autorecovery save succeeded.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f080ef9daf7519cc53f5f341bfa1d60b1ee4b964 tdf#65509 autorecovery: don't UserAutoSave during EmergencySave 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.
(In reply to Justin L from comment #58) > (In reply to Justin L from comment #57) > > "Automatically save the document" effectively disables the autorecovery, > > since the <filename>_x.odt files are removed after a successful save. > WRONG! While xDocSave does remove the old recovery files, a new one is created > immediately afterwards. I changed this with https://gerrit.libreoffice.org/c/core/+/155273. tdf#57414 autorecovery: avoid unnecessary storeToRecoveryFile Now, if the UserAutoSave is successful and the document is no longer modified, and not in SessionSave/EmergencySave, then skip creating a recovery file.