When an opened document on a network drive will be closed the semaphore file (.~lock.xxx.odt# etc.) is not deleted. I have reproduced the beavior with LO 26.2.0 beta and LO 26.8.0.0 alpha in Writer and in Calc. To reproduce the problem find or create a test document on a network ressource and follow the cases described below. Additionally watch the entries in the folder containing the test document - make show also hidden files! - When the opened document was not changed before close the not deleted semaphore file causes the document can be opened on other computers only readonly. On the same computer (and by the same user?) it can be opened without any problems. - When the document was changed LO asks for save before close. Even if the user decides to save the document or not the file attribute "readonly" is set. The next time the document can be opened only readonly. In case the user decides to "Save as" not the original file but the saved as document gets the file attribute readonly. When one tries to solve the problem by manually delete the semaphore file and clear the readonly attribute there are other problems. The document can be opened without any problems but when one tries to save the document (with or without any changes) one gets error messages as "Fehler beim Speichern des Dokuments xxx: / Kein Zugriff auf Objekt. / Aufgrund fehlender Zugriffsrechte kann auf das Objekt nicht zugegriffen werden." (ger, en [lt. Google]: "Error saving document xxx: / No access to object. / Due to insufficient access rights, the object cannot be accessed.") - test with LO 26.8.0.0 alpha - or with LO 26.2 Beta also "Fehler beim Speichern des Dokuments xxx: Fehler beim Erstellen des Objekts. / Sicherungskopie konnte nicht erstellt werden." (ger, en: "Error saving document xxx: Error creating object. / Backup could not be created.") This behavior is already described in Bug 160484.
Addition: I cannot reproduce the problem with LO 25.8.4.
Would now be nice to get a bibisect of the bug - https://wiki.documentfoundation.org/QA/HowToBibisect Please could you do it?
I have bisected the bug and here is the result: ec31a2b8d8077a1c7a9efcc3d1cd4626a643dba4 is the first bad commit commit ec31a2b8d8077a1c7a9efcc3d1cd4626a643dba4 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Sat Oct 11 08:39:15 2025 -0700 source 1a4f72f03b1bd49d486e52135e78971242fae649 source 1a4f72f03b1bd49d486e52135e78971242fae649 instdir/program/sal3.dll | Bin 680448 -> 680448 bytes instdir/program/setup.ini | 2 +- instdir/program/version.ini | 2 +- 3 files changed, 2 insertions(+), 2 deletions(-)
Based on the logs to the source ID 1a4f72f03b1bd49d486e52135e78971242fae649 given by bisect and to the Build IDs d60ff8c8bd4e3ebf8f84f53448ead3c838332ea9 (LibreOfficeDev_26.2.0.0.alpha0_Win_x86-64 from 2025-10-11_03.29.22, last Windows build with behavior OK: semaphore file was deleted) 09e5cf69b30afe46c037aca024b6014d012b0081 (LibreOfficeDev_26.2.0.0.alpha0_Win_x86-64 from 2025-10-13_03.28.43, first Windows build with the bug: semaphore file was kept at close) I think the list of changes "candidate" for causing the bug can be limited to the following: 1a4f72f tdf#150118: fix call to AccessCheck by Mike Kaganski · 3 months ago 93e3ed3 ofz Use-of-uninitialized-value by Caolán McNamara · 3 months ago 5215448 ofz Use-of-uninitialized-value by Caolán McNamara · 3 months ago 293a41d ofz#446998346 Direct-leak by Caolán McNamara · 3 months ago 9eb3f5d tdf#151144 add opencl controls to calc > calculate tab page by Sahil Gautam · 3 months ago ceb2254 tdf#151144 replace threading/opencl labels with a generic calculation label by Sahil Gautam · 3 months ago 6af1836 tdf#151144 remove opencl tab page by Sahil Gautam · 3 months ago b36f181 tdf#168777: Trailing space must show all decorations, also for ODF by Mike Kaganski · 3 months ago 3e9a613 Update git submodules by Alain Romedenne · 3 months ago
Correction to Comment 4: The Ids of the both Windows builds are reversed, sorry! correct: 09e5cf69b30afe46c037aca024b6014d012b0081 = LibreOfficeDev_26.2.0.0.alpha0_Win_x86-64 from 2025-10-11_03.29.22, last Windows build with behavior OK: semaphore file was deleted d60ff8c8bd4e3ebf8f84f53448ead3c838332ea9 = LibreOfficeDev_26.2.0.0.alpha0_Win_x86-64 from 2025-10-13_03.28.43, first Windows build with the bug: semaphore file was kept at close The resulting canditates list is OK.
(In reply to Stefan_Lange_KA@T-Online.de from comment #3) > I have bisected the bug and here is the result: > ec31a2b8d8077a1c7a9efcc3d1cd4626a643dba4 is the first bad commit > commit ec31a2b8d8077a1c7a9efcc3d1cd4626a643dba4 > Author: Norbert Thiebaud <nthiebaud@gmail.com> > Date: Sat Oct 11 08:39:15 2025 -0700 > > source 1a4f72f03b1bd49d486e52135e78971242fae649 > > source 1a4f72f03b1bd49d486e52135e78971242fae649 > > instdir/program/sal3.dll | Bin 680448 -> 680448 bytes > instdir/program/setup.ini | 2 +- > instdir/program/version.ini | 2 +- > 3 files changed, 2 insertions(+), 2 deletions(-) Thank you for bisect. Adding Cc: to Mike Kaganski ; Could you possibly take a look at this one? Thanks
(In reply to raal from comment #6) > Adding Cc: to Mike Kaganski ; Could you possibly take a look at this one? No. The identified commit only made a final change to enable commit 1b5d039d8b5861b5ea21ef00ff521c6e2565105f. When reviewing it, I made a suggestion to avoid passing PrivilegeSet to the call of AccessCheck. Balazs followed my advise, which turned out wrong. And then I simply make the change that Balazs intended to implement originally. If the abovementioned change (implemented properly) causes that unwanted consequence in not a problem of my change.
The commit 1b5d039d8b5861b5ea21ef00ff521c6e2565105f is from 2025-10-10 14:24:40 UTC and it was already in the build 09e5cf69b30afe46c037aca024b6014d012b0081. But when I understand right the answer of Mike Kaganski in Comment 7 it was still not active (enabed only by his change 1a4f72f03b1bd49d486e52135e78971242fae649 from 2025-10-11 15:28:03 UTC). OK? This could explain because the bug still didn't occur in the build 1b5d039d8b5861b5ea21ef00ff521c6e2565105f but first in d60ff8c8bd4e3ebf8f84f53448ead3c838332ea9. Could it make sense to investigate commit (change) 1b5d039d8b5861b5ea21ef00ff521c6e2565105f? The subject of this change (access check , readonly attribute, ...) does not, at least, rule out a connection to the bug.
Sorry, a wrong build Id again! Correction to Comment 8: This could explain because the bug still didn't occur in the build 09e5cf69b30afe46c037aca024b6014d012b0081 but first in d60ff8c8bd4e3ebf8f84f53448ead3c838332ea9.
(In reply to Stefan_Lange_KA@T-Online.de from comment #8) > But when I understand right the answer of Mike Kaganski in Comment 7 it was > still not active (enabed only by his change > 1a4f72f03b1bd49d486e52135e78971242fae649 from 2025-10-11 15:28:03 UTC). OK? Yes. Balazs: is implementing commit 1b5d039d8b5861b5ea21ef00ff521c6e2565105f, and his WIP passes a temporary PrivilegeSet to AccessCheck. Adds Mike as a reviewer. Mike: reads it, checks the documentation of AccessCheck, sees that PrivilegeSet is documented optional, and suggest to avoid that instead. Balazs: follows Mike's advise, and merges commit 1b5d039d8b5861b5ea21ef00ff521c6e2565105f. Mike: sees the commit has been merged, pulls fresh master, builds, and tests - and sees that the intended functionality is not working at all. He debugs it, and sees that the call to AccessCheck fails; he tests that the failure is causes by not passing PrivilegeSet to it; then he creates and merges follow up commit 1a4f72f03b1bd49d486e52135e78971242fae649, which result is simply "Balazs' original change".