There is no problems on Windows because of two facts: 1. Windows supports file shortcuts, but Linux by default supports only symbolic and hard links. 2. Windows locks files, open for update, then other processes cannot modify these files. Linux doesn't provide default file locking. On Linux, LibreOffice behavior doesn't satisfy best practice. 1. Unlike most text editors, LibreOffice doesn't analyze if a selected file is a symbolic link. LibreOffice opens every symbolic link in a separate window as a different file instance. That allows LibreOffice users to simultaneously modify the same file in different, unrelated, windows that leads to much confusion. 2. The lack of a default file locking mechanism on Linux is normally resolved by file timestamp validations. Usually the timestamp is being validated in three cases: when a window gets focus, periodically during the editing session, and right before saving on disk. However, LibreOffice validates timestamps only in one case, before saving, when users already finished their work. LibreOffice checks the timestamp only one time, after the first attempt to save. The subsequent attempt will overwrite the file on disk without any further confirmation. 1. LibreOffice should validate symbolic links and should not allow opening multiple windows for the same target file, when possible. 2. LibreOffice should validate timestamp before every save command and ask for confirmation every time when the timestamp differs. Not just once.
Please, describe a step by step scenario showing that there is a problem under Linux. My test: 1/ be an existing file foo.odt in the folder A 2/ create a simlink of foo.odt in the folder B 3/ open A/foo.odt 4/ open B/foo.odt 5/ make a change in A/foo.odt 6/ make another change in B/foo.odt 7/ go back to A/foo.odt, then ctrl+S => A/foo.odt is saved 8/ go back to B/foo.odt, then ctrl+S => Warning message that this file as been modified since it has been open in LibreOffice for edition. Saving this version will overwrite previous changes made by others. For me that is the expected behavior. Status set to NEEDINFO, please set it back to UNCONFIRMED once requested informations are provided. Best regards. JBF
Hello, Jean-Baptiste, This is a design bug. LO behavior is consistent, but wrong from my point of view. Your scenario is right, just it is incomplete. Please, add to more steps: 9/ press cancel 10/ press ctrl+S again. At this point you will not get any confirmation, the content B/foo.odt will be saved. The program should confirm with users every time when the timestamp is old. Also, please, take a look at step 4. open B/foo.odt. Why is the symbolic link opened as an independent file? The advanced text editors on Linux easily recognize symbolic links and process symbolic links as target files. I mean such editors as gvim/vim, emacs, geany, visual studio code, kate, and many more. In my career I was presenting Linux and LO to few small offices, and I know many real cases when users, with Windows background, lost content. Let’s take another look at your scenario from human perspective. Step 8: an user, familiar with Windows shortcuts, could be not aware that B/foo.odt is a symbolic link. Getting a warning message will entirely surprise this user. Then, normal actions from users are: cancel saving and rapidly move all changes made in B/foo.odt to A/foo.odt. Both windows have to same title, so, it's very easy to make a mistake and press ctrl+S in the wrong window. Especially when users can assume that in case of a wrong window LO will warn again. However, LO doesn't do it.
Fair enough, let's set to NEW
Dear yury.dubinsky, 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
I re-tested per your suggestion. I installed 6.2.4. Unfortunately, this behaviour was not changed. There are steps that I performed. 1. Create a text document. (Or any other LO file) 2. Create in another directory a soft link to this file. 3. In any file manager click the original file and the link. LO will open the file and the link in two separate windows. 4. Make a change in one window and save it. 5. Make a change in another window and try to save. You will receive the pop-up warning with two options: save anyway or cancel. Press Cancel and then save again. The content of the file will be overwritten. To avoid this problem, we need to check the file timestamp before each save, and not just the first time we try to save. In addition, most editors check the timestamp every time the window becomes active. Then users will be informed before they start changing the content.
I repro'd this on Windows 10 64-bit using LibreOffice 7.2.0.0 dev build. This happens on Windows now due to the following regression I found: https://bugs.documentfoundation.org/show_bug.cgi?id=141279
Matt K committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/07250a832787acdd432dccd458536de2987a58b2 tdf#117967 Fixes Save confirmation dialog for user cancel It will be available in 7.5.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.
Thanks for the commit. Any more work needed or can this be closed as fixed?
(In reply to Buovjaga from comment #9) > Thanks for the commit. Any more work needed or can this be closed as fixed? It can be closed ... updating status.