With any documents, the office makes a working directory of the form
/home/test/.local/share/onlyoffice/desktopeditors/recover/DE__d0pJOd where the actual work with the new version of the file takes place.
Saving a document copies the new version of the document to its original location. Often there is a situation when two or three users open a file for work and as a result we get a document in the form in which it was retained by the last editor. All changes made by other users are lost.
I ask you to implement the blocking function based on the creation of Owner File ,
which will also enable collaboration with Microsoft Office users.
Sorry for the late reply.
Would you mind providing us with exact issue scenario?
If you use Desktop editors as is, you can use it locally only (without simultaneous editing). You have described case when a few users work with the same file. Do I understand it right that you have connected some cloud storage such as Nextcloud\Seafile\etc. (and you work with the file from that storage in your usage case)?
Please provide us with step by step issue scenario, we will check it out.
We do not use cloud storage. Collaboration is carried out on the shared resources of the SAMBA and NovellNetware servers.
From the user’s point of view, these are just local directories (mounted file systems), for Windows users, these are additional disks, respectively.
Problems arise when several users open the same file for editing. Operating system system calls allow you to lock files or areas of files on network resources, but this is useless in view of the fact that OnlyOffice makes a local copy of the file for itself and overwrites the final file on the network resource when editing (saving) is completed.
Thank you for your description, we are checking the situation.
We have checked mentioned scenario. This is known bug (internal number - 44577).
We have added your request to mentioned bug. We are working on it already.
Sorry for inconvenience.
It seems like a lock file is being created, but I confirm the incorrect behavior on network resources that you described.
I do not find the lock file in the folder where the file being opened is located (neither hidden nor open).
Sorry, we are still working on it. I will update this thread when we have something to share.