If a symlink in one folder refers to a file in another folder, then the lockfile created when the file is opened does not protect against a second instance of LibreOffice Calc opening the same file via the symlink. This can lead to loss of data caused by one user updating a file and the results being overwritten by another user saving his different updates. Or even by the same user forgetting that he already has the file open. It's therefore a major or even critical bug. Affects both calc and writer so reported under LibreOffice. To verify -create (say) /home/user/Documents/t.odt -in terminal, ln -s /home/user/Documents/t.odt /home/user/Desktop/ -navigate to Documents (I used nemo) and open t.odt by double-clicking -doubleclick the link to t.odt on the desktop, and a second writer instance appears with the same file open and no error message -verify potential data loss by changing in one instance and saving, then changing diffedrently in the second abd saving.
Not reproducible for me with LO 6.0.5 under Ubuntu 16.04: when I try to save the second file, I get the following warning message: The file has been changed since it was opened for editing in LibreOffice. Saving your version of the document will overwrite changes made by others. Do you want to save anyway? Did you set User Data in Tools > Options > LibreOffice so that the program can known which user is editing the file? Status set to NEEDINFO, please set it back to UNCONFIRMED once requested informations are provided. Best regards. JBF
Can confirm that status with 6.0.5 is as stated by JBF. However, I would still call this a serious bug. The correct situation would be that as soon as an attempt to open the file via a symlink is made, then if the target file is already open and protected by a lockfile the user should be made aware of this (including aware of who has it open -- contents of the lockfile, decoded), and then offered the choice of opening read-only or abandoning his attempt to work on the target file at this time. With the 6.0.5 behaviour the two users may make incompatible changes representing several hours work, and although a later save does not overwrite the earlier save, this is a mess to sort out which would have been avoided had the program worked as per the previous paragraph. This correct behaviour is what happens if two users attempt to open the same file simultaneously other than via a symlink. (Confirmed on 6.0.5) The target ods files are on an NFS 3 share, which might be relevant.
Warning the file has changed since opening is not the same as detecting it's already open when opening it. These are 2 different messages. If you try to open a file twice using the proper direct path to the real file, you should get a warning that it's already open, and choice of opening read-only or making a copy. Basically, you get blocked from opening it. I haven't personally noticed this specific issue, but it's probably the same underlying issue I do have - symlinks get destroyed and replaced with a normal file upon saving. If LibreOffice is looking at the symlink location as the file path, then it no doubt saves by destroying the "file" path (which is a symlink) and creating a new file. If the symlink was followed instead, I think both issues would be solved together.
> I haven't personally noticed this specific issue, but it's probably the same > underlying issue I do have - symlinks get destroyed and replaced with a > normal file upon saving. If LibreOffice is looking at the symlink location > as the file path, then it no doubt saves by destroying the "file" path > (which is a symlink) and creating a new file. If the symlink was followed > instead, I think both issues would be solved together. I guess that was bug 119381 which is now fixed in LibreOffice 6.1.1 or higher
Dear Nigel Arnot, Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Dear Nigel Arnot, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear Nigel Arnot, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp