File locking blocks seamless switching from online to local editing

[jancborchardt]

Recently with Text files (md and txt) I often have issues that they are "locked" by the Text app, or my server account.

If I quickly (or even not soo quickly) switch between editing them collaboratively online, and in my local text editor, the local version is locked and I get issues. Then need to close it online and wait for lock release Also, the "lock" icon in the web interface is a bit misleading if added because someone on the web works on it, as in that case it is totally fine to collaborate (same actually for Office).

Before, I didn’t experience any issues, new things just synced down, the editor updated the file in the background, and the switch was seamless. And there was no confusion regarding a lock icon showing up even though everyone was just collaborating online.

@juliushaertl @AndyScherzinger @nimishavijay any thoughts on that? Also cc @karlitschek regarding the seamless local edinting & locking for Office. Should we have some exceptions here, or could that create issues?

[juliusknorr]

Well this is of course how the locking feature is meant, as we want to avoid that people overwrite changes on the desktop client while others are editing the document online.

Before, I didn’t experience any issues, new things just synced down, the editor updated the file in the background, and the switch was seamless. And there was no confusion regarding a lock icon showing up even though everyone was just collaborating online.

So this would be about closing text in the browser and getting the changes back to desktop. That should still work the same way, assuming that the desktop client gets the change and immediately also checks if the file is unlocked, so maybe that is something to check back with the desktop team.

This is also the only part where the behaviour should have changed, considering that you do not manually lock the file on the desktop client.

[marcelklehr]

Well this is of course how the locking feature is meant, as we want to avoid that people overwrite changes on the desktop client while others are editing the document online.

I agree. While editing a file on desktop the changes will not be synced to the text app session until you save and thus potentially override changes made meanwhile on the web by other people. Of course, if you are the only person editing the file on the web, the locking potentially introduces friction, if you forget to close the text app before opening the file on the desktop. IMHO, the potential to override changes is worse.

So this would be about closing text in the browser and getting the changes back to desktop.

As far as I can test this still works fine ,atm and is for me quite fast.

Also, the "lock" icon in the web interface is a bit misleading if added because someone on the web works on it, as in that case it is totally fine to collaborate (same actually for Office).

This is something I would potentially agree on. As it is, it's not entirely self-explanatory what is happening here: