Description: If you save a file that's already open in LibreOffice using a different program such as Notepad, the save operation is allowed by the OS and overwrites the file. This is not allowed when the file is open using LibreOffice version 7.1.1.2; the saving program gives an error stating that the file can't be saved. Steps to Reproduce: 1. Create a file "test.ods" and open in it LibreOffice, add some edits and save it 2. Open a text editor such as Notepad and save a blank document overwriting "test.ods" (save as type "All Files"), and observe no error dialog upon saving 3. In LibreOffice, do File->Reload and observe blank document Actual Results: Blank document due to overwrite Expected Results: Document should keep edits and not be overwritten Reproducible: Always User Profile Reset: No Additional Info: Observed on Windows 10 64-bit
I guess the problem is on the OS side. I tried under Ubuntu and my text editor showed a warning saying that the file already existed. At least the problem is not on the LibreOffice side. If the text editor accept to overwrite without notice an existing file, LibreOffice can do nothing when the user ask to reload the file. You should report this bug against your OS. Closing as NotOurBug. Best regards. JBF
> If the text editor accept to overwrite without notice an existing file If the file is locked by the in-use process, any editor will fail to overwrite. The problem is the file is no longer being locked by LO. > You should report this bug against your OS. This bug is due to how LO opens files. I bibisected the bug to the following change: 2b4cd99d3360ccffb9829a02412824864d045753: "tdf#126742 make Windows file handling more unx-like" Added Armin Le Grand to CC list for any feedback about this. Resetting status.
Adding Mike to CC list as well due to his comments on https://gerrit.libreoffice.org/c/core/+/112237
Took a look at change. The discussion in https://gerrit.libreoffice.org/c/core/+/112237 says: "Made a quick test on Windows with a test.txt and notepad/LO with/without that patch, behaves the same. Can in both cases open vice-versa, change and save. Notepad goes on 'save as...' when LO changed file already, we do not do that - but this is also the same on bith versions." and "WP, LO without patch: opening on WP first -> can open with LO and safe, checked changed WP, LO without patch: opening on LO first -> cannot open wth WP WP, LO with patch: opening on WP first -> can open with LO and safe, checked changed WP, LO with patch: opening on LO first -> cannot open wth WP -> looks good AFAICT" What means that this is probably no regression. The error (all Win only here) that you can write to a file from another app was/is there all the time, but that fix allows to correct the behaviour of locally included OLEs like charts. Mike also states there that: "Please do not test with Notepad. It is a kind of exception on Windows, opening files for reading then closing file handle, and trying to open them for writing when saving. Please use at least WordPad, which uses typical "open and lock" pattern." So it would be helpful if you check with WordPad, please. I will re-check on Win in the meantime...
Check with Notepad (*.docx) With current master: (a) Open in LO, try to open in WordPad -> WordPad refuses to open, OK (b) Open in WP, try to open in LO -> Works. Changed in LO, saved. Have to close LO, then open in WP -> got changed, NOT_OK With git revert 2b4cd99d3360ccffb9829a02412824864d045753: (a) same, OK (b) same, NOT_OK -> no change in behaviour, so no regression -> still (b)'s NOT_OK is an error, but an old one not caused by the change. It should be fixed (no idea how, tough) So I would like to remove the regression flag. HTH!
Argh! In Comment5 of course replace "Notepad" with "Wordpad" (Notepad is not capable of *.docx)
Created attachment 182154 [details] Error message from Notepad when trying to force-overwrite file open in Writer 6.4 Can confirm the behavior change. When a file (type such as txt, odt, docx does not matter) is open in an older LO version, or Word 2016, doing the following in Notepad: - Create new file - Save as the already open file - Confirm save as dialog: $file already exists, do you want to replace it? -> Yes Results in the error message on this screenshot: The process cannot access the file, because it is being used by another process. 7.1 from the bibisected commit until current master allows notepad to overwrite the file currently open, before it did not. Wordpad is more clever and does not destroy already open files this way. It says "The document $file is already in use by another application and cannot be accessed" when trying to force-overwrite.
Created attachment 182155 [details] Notepad destroyed the already open odt file Note the file name in the Notepad title bar - same as in LO, which cannot reload the previously opened odt file since it's a txt now.
Extra-check with Notepad (*.txt): With current master: (a) Open in LO, open in NP works, can change, save, asks for replace (so somewhat sees that it was changed and held by some other app?), but works -> NOT_OK (b) Open in NP, try to open in LO -> Works. Changed in LO, saved. Have NOT to close LO, Open in WP -> got changed -> NOT_OK With git revert 2b4cd99d3360ccffb9829a02412824864d045753: (a) Open in LO, open in NP works, can change, save, asks for replace (so somewhat sees that it was changed and held by some other app?), CANNOT_ACCESS -> OK (b) same -> NOT_OK So I also acknowledge a change for Notepad, but have to repeat here from comment 4: "Please do not test with Notepad. It is a kind of exception on Windows, opening files for reading then closing file handle, and trying to open them for writing when saving. Please use at least WordPad, which uses typical "open and lock" pattern." If we do not want to loose again the fix from https://bugs.documentfoundation.org/show_bug.cgi?id=126742 we should IMHO ignore Notepad. That fix is needed to be able to change local OLE files when changes happen, e.g. edit table content & Chart updates. We could also think about 'somehow' fix this for Notepad, but that file opening is so central that I personally would not want to risk it. Also out of question is something like to check if Notepad is running in parallel on the local system and do something 'special'...(?) Just my 2ct...
So lets conclude this seems impossible to make work for all the different use cases. The current state is at least consistent across platforms (Linux and Windows), and more coherent with other applications' behaviour. Sadly, it seems impossible to fix all issues at the same time (so there has to be this trade-off). Closing as WONTFIX for the moment, but if there's new ideas or input (or creative ideas how to have our cake here & eat it), not against reopening.