It's difficult to monitor file changes correctly

[sumneko]

To support global variables, the server needs to monitor all file additions and deletions, so I use the workspace/didChangeWatchedFiles to do that.
However, this protocol is difficult to use correctly, for example:

User's operation

• Copy and paste a folder containing two files.
• Modify the name of this folder.
• Delete this folder.

Expected to receive

• Create two files.
• Delete two files and create two files.
• Delete two files.

Actually received

• Create three files or folders, I need to judge which is file by IO myself.
• Remove a file or folder and create a file or folder, I need to determine that this is a folder rename so that I can correctly modify the name of the internal two files.
• Remove a file or folder, I need to remove the internal two files by myself.

I have read some other issues like microsoft/vscode-languageserver-node#141, it seems that this is your design, but this design is very difficult to use, even in addition to the server's own IO, there is no good way to determine whether to add files or folders.

[dbaeumer]

There is always the possibility that the server does its own file watching without asking the client for events.

[sumneko]

I'm glad to see that you've added a file operations protocol.

The new protocol solves the problem of renaming, but the support for folders is still unfriendly.

At present, if I delete or rename a folder, the protocol only informs the server of the change of the folder (and only provides a URI, which does not indicate whether the URI is a folder or a file).

In fact, most language services don't care about folders. Files are the basic units.

Therefore, I hope that the protocol of file operation can be further strengthened in the future. For example, the option can be added to let the client split the folder event into internal file events (for example, when a folder with 10 files is deleted, the URI of these 10 internal files will be provided in the deletion event).

Finally, thank you for your work!

[sumneko]

I found that file events protocol only responds to VSCode operations, not external file operations.

In the real environment, people often create new files because of pulling git. At this time, new files cannot trigger file events protocol.

Is this the design?

If the design is like this, the file events protocol may not be able to meet my needs.

[dbaeumer]

The design is like this since it allows to return additional edits in case of a rename (see the will*) requests. The file operations are not a replacement of the file events.

Most file system don't provide you with events and of the children even a folder is renamed. If clients might not know the children since the node might have never be presented in an explorer. Scanning the whole file system on the client to simple provide these fine grain events is IMO not the right solution. Since a server knows the files that are loaded into a project it IMO can "easily" compute this itself.

[sumneko]

Thank you for your patience and help. I will change to the server to deal with this problem. You are free to close this issue.

[dbaeumer]

@sumneko thanks for getting back. Closing.