Description: After updating LibreOffice to version 7.6.2.1 on our employees’ PCs our users realized they can modify files located in shared folders (Active Directory shares mapped to disks) which are currently opened by someone, modify it and save changes without original editor’s knowledge. When user tries to open „locked” file he gets an error saying the file is locked by someone, has options „Open R/O”, „Open Copy” and „Open” at the bottom of window. When he chooses the last option he can modify file and nothing stops him from overwriting this file in it’s original location. IMHO this should not happen and it’s dangerous becasuse e.g. user may perform calculations in spreadsheet file basing on outdated data just because he simply doesn’t know that file has been modified. This problem happened in LibreOffice Writer and Calc, I guess the same will affect rest of Libreoffice programs. Steps to Reproduce: 1.Alice opens file in shared location and she’s working on it, making some changes, saves file with e.g. CTRL+S shortcut, keeps file open, .lock file is created in filesystem, 2.Bob tries to open file, which is currently opened by Alice, error is shown saying file is locked by someone and user has to choose what to do, 3.Bob has options „Open R/O”, ”Open Copy”, ”Open”, chooses „Open” at the bottom of a error window, file opens, 4.Bob modifies file like nothing ever happened, saves it, sees no more warnings, 5.When Alice tries to save her work (nothing is shown earlier!), she gets an error saying the file has been modified by someone. Actual Results: Bob is able to open and modify a file on which Alice is currently working. She doesn’t know the file has been opened for editing and modified by someone else until she tries to save her version of file with e.g. CTRL+S shortcut. She gets an error. When she re-opens that file she can see what has been modified. She can save her version of file by choosing "Save anyway", but she will never know WHAT has been modified and WHO did it. Expected Results: Bob should be allowed only to open file on which Alice is currently working in R/O mode or to create a local copy on his PC. MOdifying a original file in it’s original location should be impossible until .lock file is removed (automatically or manually in File Explorer if something went south) Reproducible: Always User Profile Reset: No Additional Info: Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: pl-PL (pl_PL); UI: pl-PL Calc: threaded
Definitely a fallback from commit 2b4cd99d3360ccffb9829a02412824864d045753.
i can confirm we're using version of LO 7.4.3.2 Windows 10 and have same behavior
2b4cd99d3360ccffb9829a02412824864d045753 made it into 7.2.0.0alpha0+, but I'm setting the earliest version to tsulayaiv's for now. root and tsulayaiv, do you remember how it used to behave before? Would the dialog only offer the two options „Open R/O” and ”Open Copy”? Armin, what do you think? Reading your commit, this is by design, right? I'm all for more consistency between OS, but I can see the issue in making it this easy to do. Is there a corresponding expert configuration that could block from editing when a lock file exists? That would be useful for system admins wanting to have tighter rules. I see we have bug 120829 already. As stated there, we might just need a clearer, strong warning in the dialog about the consequences of opening with an existing lockfile. See the comments in bug 120829, especially the UX/Design team comments. Would you agree with such a solution, root and tsulayaiv?
(In reply to Stéphane Guillou (stragu) from comment #3) The dialog is just a visual manifestation. The essence is that now, LibreOffice does not use the filesystem locking as it used to do before - so that *another process is able to write into a file opened by LibreOffice*. Previously, Windows filesystem would prevent it physically - no matter what you tried, OS (filesystem driver) would prevent writing into such an open file.
Hello, I checked few of our employees' computers with LibreOffice 6.4 and 7.5 installed and uploaded 2 screenshots - as you can see, in LibreOffice 6.4 users couldn't modify file opened by someone - there is no such option (translation:"Open read-only","Open copy","Cancel"). In LibreOffice 7.5 users CAN modify this file by clicking "Open". Also in LO 7.6 happens the same. AFAIR in LibreOffice 7.4 had the same dialog window as LO 7.5, so @tsulayaiv can be right.
Created attachment 190802 [details] File opened by someone - LO6.4
Created attachment 190803 [details] File opened by someone - LO7.5
On Windows with several LO versions installed in parallel: 1. Open any (local) document using an old LO version (say, 7.0); 2. In the directory where that document is located, see and delete the lockfile (so that the lockfile doesn't interfere with the real issue); 3. Open the same file in a new LO version (say, 7.6). => the "Document in use" warning does not allow you to open the file for editing, only R/O or as a copy. The following steps 4-6 should be done in the newer version (in my example, 7.6). 4. Open it R/O; 5. Try to enter the Edit mode (e.g., using the infobar's "Edit Document" button, or Edit->Edit Mode (Ctrl+Shift+M)) => the same warning will appear, and again, it won't allow you to open in edit mode. 6. Try to Save As -> same name => An error will appear: > Error saving the document XYZ: > Write Error. > Document opened as read-only cannot be saved over itself. 7. Close the newer version (7.6), but keep the document open in 7.0; try to delete the document from Explorer, or try opening it in Notepad, delete the binary "garbage", and save. => Both actions will fail. The older version used the OS means to prevent any change of the file on disk (locking + appropriate sharing flags); so the file opened for writing in one session, couldn't be modified in any other session. This also applied to Windows shares, so users in Windows network were safe in this regard. This followed the Windows OS paradigm of working with files; note that this paradigm is different from that common in Linux world. ====== Now repeat the same procedure (steps 1 - 7), but in step 1, use a newer version - say, 7.5. a) After step 3, the warning dialog will not appear at all - the document will open without any warning in the second editor, in Edit mode; this means, that steps 4 and 5 don't even make sense. b) Step 6 succeeds, meaning that now the file is not protected on disk at all. c) Step 7 doesn't succeed, showing that at least some locking is still in place. Note that while saving with notepad fails, saving using notepad++ succeeds.
So *possibly* we should try to follow the notepad way (as opposed notepad++), and only allow saving in a completely unrestricted sharing mode (needs experimentation). But wouldn't that mean, that the fix made in the commit 2b4cd99d3360ccffb9829a02412824864d045753 would then become ineffective - we will again treat such files as read-only, and that commit will not reach its goal? Possibly a better way would be to only limit the "more unx-like" file handling to a specific set of situations, like own temporary files - which is what happens when opening embedded OLEs, which was mitigated there.
>I see we have bug 120829 already. As stated there, we might just need a clearer, >strong warning in the dialog about the consequences of opening with an existing >lockfile. See the comments in bug 120829, especially the UX/Design team comments. >Would you agree with such a solution, root and tsulayaiv? @stragu IMO there should be no option to open and modify currently opened file by someone else at all. Non-technical users may still open it anyway, causing trouble and mess. When we used LO 6.4 it was simple, we could see who is working on file and call them: "-Hello XXX, could you close file YYY? I would like to add something to it" "-Yeah, sure, gonna save my changes, gimme a minute".
(In reply to Mike Kaganski from comment #8) > On Windows with several LO versions installed in parallel: > > 1. Open any (local) document using an old LO version (say, 7.0); > 2. In the directory where that document is located, see and delete the > lockfile (so that the lockfile doesn't interfere with the real issue); > 3. Open the same file in a new LO version (say, 7.6). > > => the "Document in use" warning does not allow you to open the file for > editing, only R/O or as a copy. > > The following steps 4-6 should be done in the newer version (in my example, > 7.6). > > 4. Open it R/O; > 5. Try to enter the Edit mode (e.g., using the infobar's "Edit Document" > button, or Edit->Edit Mode (Ctrl+Shift+M)) > > => the same warning will appear, and again, it won't allow you to open in > edit mode. > > 6. Try to Save As -> same name > > => An error will appear: > > > Error saving the document XYZ: > > Write Error. > > Document opened as read-only cannot be saved over itself. > > 7. Close the newer version (7.6), but keep the document open in 7.0; try to > delete the document from Explorer, or try opening it in Notepad, delete the > binary "garbage", and save. > > => Both actions will fail. > > The older version used the OS means to prevent any change of the file on > disk (locking + appropriate sharing flags); so the file opened for writing > in one session, couldn't be modified in any other session. This also applied > to Windows shares, so users in Windows network were safe in this regard. > This followed the Windows OS paradigm of working with files; note that this > paradigm is different from that common in Linux world. > > ====== > > Now repeat the same procedure (steps 1 - 7), but in step 1, use a newer > version - say, 7.5. > > a) After step 3, the warning dialog will not appear at all - the document > will open without any warning in the second editor, in Edit mode; this > means, that steps 4 and 5 don't even make sense. > > b) Step 6 succeeds, meaning that now the file is not protected on disk at > all. > > c) Step 7 doesn't succeed, showing that at least some locking is still in > place. Note that while saving with notepad fails, saving using notepad++ > succeeds. dmn, that's some good weed you have there man)) so mine guess the devs just can't revert back those changes and made it like it was before? ps for now we switch to OO for a couple of users that desperate for that window back (and i can tell they ain't happy about it))
(In reply to Stéphane Guillou (stragu) from comment #3) > I see we have bug 120829 already. As stated there, we might just need a > clearer, strong warning in the dialog about the consequences of opening with > an existing lockfile. See the comments in bug 120829, especially the > UX/Design team comments. > Would you agree with such a solution, root and tsulayaiv? im agree with UIx where there is no button that allow user to open already opened document (to make changes i mean) only in R/O. sorry if i'm asking for too much))
(In reply to Mike Kaganski from comment #8) > [...] > Now repeat the same procedure (steps 1 - 7), but in step 1, use a newer > version - say, 7.5. > > a) After step 3, the warning dialog will not appear at all - the document > will open without any warning in the second editor, in Edit mode; this > means, that steps 4 and 5 don't even make sense. > [...] Thanks for the testing, Mike. For this at least, let's mark as "new". (In reply to tsulayaiv from comment #11) > dmn, that's some good weed you have there man)) ???
Created attachment 191538 [details] if open in excel then dialog window in LO works fine we've noticed that if a file already open in excel then if trying to open same file in LO the button Open is greyed out and doesnt allow to open file (how it should be)
The problem is that this function is critical * it can lead to the loss of a document. * The documentation is not up to date. * The user interface is not complete, with a third 'open' button whose role is not very well defined.