I’m using the macOS VFS client (3.17.1) on macOS Tahoe, and whenever I have a Microsoft Office file open (e.g., a PPTX in PowerPoint), the file gets auto-locked at some point, which means that I cannot save it anymore (“The document could not be saved.”). I have to manually unlock the file in order to continue saving changes.
I’m not sure if this is intended behavior, since auto-locking makes sense to prevent other users from modifying an open file, but the current behavior prevents changes even if just one person has the file open.
Hi! This is a known issue and under active investigation. The locking is intended but not working as it should and you have observed. We have several reports of this and I just talked about this in particular moments ago with my colleague. There might be a timing issue with processing events and file changes.
Thank you @iva.horn! For now I just manually unlock the file, and as long as I have the file open I don’t think that it gets auto-locked again. If there’s a GitHub issue it would be helpful to link that here for reference.
There is no public issue yet (which I am aware of). One of our subscribed customers reported it through or support portal, though, and that suffices for us to track and act on it.
For us it would be very helpful to have a public one, so we can link people to it and they can follow the status. If it is handled properly, they know which release contains the fix, and they can then test from their side and give feedback.
I agree, it would be very helpful to have an open issue in your GitHub repository so that interested people can follow the progress. Would it be OK if I create an issue? I’m asking because this issue is really really annoying (basically I have to save my documents under a different name, then delete the old one and rename the new one, since “Unlock file” now tells me that “the file is already unlocked”, which is not true).
I would like to point out that the (un)locking issue was resolved meanwhile.
I’m not sure if this is intended behavior, since auto-locking makes sense to prevent other users from modifying an open file, but the current behavior prevents changes even if just one person has the file open.
That is the point of it. This is the expected behavior as requested by our customers and users. On file system level, we cannot distinguish with what intention (just viewing or actually modifying) a user is opening a file and third-party apps like Microsoft Office create a lock file regardless.
I would like to point out that the (un)locking issue was resolved meanwhile.
Thanks for pointing that out, this is great!
Since the issue is resolved, it’s a moot point now, but I still find it hard to believe that customers asked for an Office file to lock even for the person who opened it. Auto-locking the file for other users makes sense (as you pointed out, Microsoft Office already creates its own lock files), but locking out the owner does not. The only sensible approach is to let the apps manage locking themselves, and thankfully that’s now how it works!
Now I understand that better, that is a different issue we have reports about in the past. Sometimes the file was locked for the owner themselves. This was resolved by the adoption of the token based locks which means: The client device setting up the lock is “owning” the lock identified by a token which also is then released by it.
The locking is intended but not working as it should and you have observed. We have several reports of this and I just talked about this in particular moments ago with my colleague. There might be a timing issue with processing events and file changes.