When we implement a virtual file system, the API spec dictates that we need to implement a watch functionality. We have one in progress here in the azure-storage extension. Thanks @monalgarg!
Setting up a FileSystemWatcher does not keep track of URI's related to the virtual file paths. Details in this StackOverflow post.
One alternative I see is having a side-process that frequently polls the virtual file system for changes, and emits them on VSCode. We noticed that VSCode does a lot of stat calls to the File system (in building the file tree for the explorer), so us implementing this watch seems like there would be :
- repeated logic/code across multiple explorer providers.
- Inefficient, since VSCode's stat calls would return information that can be used here (for e.g., create and delete events on files and folders). Us making the similar calls again can be rate-limited by the service serving up the virtual files/folders.
Can my blocker be side-stepped by another approach?
If not,
Is there a way to make it easy to have a FileSystemWatcher watch virtual URI's without a lot of repeatable scaffolding?
When we implement a virtual file system, the API spec dictates that we need to implement a watch functionality. We have one in progress here in the azure-storage extension. Thanks @monalgarg!
Setting up a FileSystemWatcher does not keep track of URI's related to the virtual file paths. Details in this StackOverflow post.
One alternative I see is having a side-process that frequently polls the virtual file system for changes, and emits them on VSCode. We noticed that VSCode does a lot of
statcalls to the File system (in building the file tree for the explorer), so us implementing this watch seems like there would be :Can my blocker be side-stepped by another approach?
If not,
Is there a way to make it easy to have a FileSystemWatcher watch virtual URI's without a lot of repeatable scaffolding?