First - I haven't being able to reproduce the issue. Before I even begin, let me just start to inform that the location of the LibO backup folder are placed on a shared network drive, and I know from before that this particular network drive has caused issues in the past, also to other programs - probably because it can fail when a program try to write to it. It can periodically fail for some seconds and then suddenly of itself get to work like nothing happens, and can read and write to it normally. Therefore I assume the solution is probably in the way LibO respond in a case where the backup folder for some reason stop to allow processes to read/write to it. So I'd put this as a feature request because I don't think it's a bug (never happens when I use Linux at home). Version: 7.6.7.2 (x86) / LibreOffice Community Build ID: dd47e4b30cb7dab30588d6c79c651f218165e3c5 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: nb-NO (nb_NO); UI: en-US Calc: CL threaded Steps to reproduce: * Have the LibO backup location to an unstable network drive. * Use LibO normally for a long time, but if and when there is r/w issues to the backup location, then: * Open file * Save file as another file name - Save file : this will cause a generic message that says "document cannot be saved" (unfortunately I lost the printscreen for that message and can only reply as I remembered it worded) - Save as : Same result, get the same error message and cannot save the file. - Save as to another location (to a known working usb drive) - same result, LibO fails to create the files with the changes. - In the LibO backup dir, only a copy of the file as it was when saved the first time is located there. That means all changes to the file (spend half an hour) is lost and there is nothing I can do to correct this. This suggest there is a problem to the backup directory itself (my theory). After I closed LibO and opened again, I was able to save and save as normally without any issues. Suggested solution: When the backup folder for some reason disconnects, LibO should be able to pick up on that instead of preventing the current opened file to be written to.
Thanks for the report. (In reply to Grobe from comment #0) > First - I haven't being able to reproduce the issue. > [...] > * Have the LibO backup location to an unstable network drive. > * Use LibO normally for a long time, but if and when there is r/w issues to the backup location, then: I might be pessimistic, but I don't think anyone will be able to recreate these conditions and confirm the issue. > * Open file So the file is opened _after_ the network drive fails, and the file is _not_ located on the network drive? > - In the LibO backup dir, only a copy of the file as it was when saved the > first time is located there. That means all changes to the file (spend half > an hour) is lost and there is nothing I can do to correct this. This suggest > there is a problem to the backup directory itself (my theory). What exactly are your options in Tools > Options > Load/Save > General? Also, please test with a version that is currently supported, e.g. 24.2. (The 7.6 branch won't see further releases.)
(In reply to Stéphane Guillou (stragu) from comment #1) > I might be pessimistic, but I don't think anyone will be able to recreate > these conditions and confirm the issue. Or would simply disconnecting the drive result in the same issue?
Actually, I understand this to be the same as bug 103085: if the backup location is not available for writing (for whatever reason), LO should let the user know. *** This bug has been marked as a duplicate of bug 103085 ***