search

mattiamerzi / vs.remote

A Visual Studio Code remote filesystem implementation with dotnet core backend, based on protocol buffers, gRPC and asp.net
MIT License
2 stars 0 forks source link

Save Conflict Resolution #3

Open miboper opened 3 months ago

miboper commented 3 months ago

Hi,

When editing a file on a local file system VSCode detects if the file was modified outside of the environment and gives a warning when saving local changes. User can then overwrite, cancel, or proceed with a conflict resolution. Does the remote file system support this pattern when a remote file was modified by someone else while the user is editing it? What is the best way to detect and handle these conflicts?

Thank you!

mattiamerzi commented 3 months ago

Hello Michael,

sincerely it's a scenario I've never tested, but it's something that I cannot directly control using a filesystem extension.

I guess that, as long as you provide consistent mtime/ctime timestamps with your fs answers, VsCode should correctly handle this scenario.

If it doesn't work, the only thing I can do is to send the latest known mtimes along with any gRPC call and verify timestamps server-side. Regarding the "conflict resolution" functionality, if it's not automatically handled by VsCode, I will dig into this.

I will try this out as soon as I can and let you know how it goes.

Thanks a lot,

Mattia.

miboper commented 3 months ago

Thank you for your response, Mattia.

I thought of catching this on the server, but unfortunately the client makes the stat call just before the writeFile and sends the file metadata (including the MTime) along with the writeFile. So the server sees the metadata that corresponds to the server version of the file instead of the one the metadata corresponding to the version of the file at the time editing has started. And even that only happens with the index-based implementation of the server -- path-based implementation doesn't receive any metadata with the writeFile call. Last point aside, to make this work on the server the extension would need to hold onto the file metadata at the time of the last file read (just before the editing starts) and send that metadata with the writeFile call instead of getting the latest metadata from the server just before the writeFile.

Ideally, however, we'd want to tap into the vscode's existing conflict resolution workflow that it already performs for the local files. In that case the stat call just before save even makes sense -- to get the latest server version to compare to what we have locally and then give user choices for how to deal with the situation. Maybe it's something vscode team just forgot to include for the file system provider scenario?