Support for File System APIs

[gbrueckl]

Are there any plans to also support custom VSCode FileSystemProvider
i am currently working on two VSCode extensions which heavily rely on them and it would be great to compare different files and folders from my custom file system.

its basically about exchanging all references to fs with vscode.fs and slight modifications if some functions are different/not there

regards,
-gerhard

[moshfeu]

Thanks for the reasonable suggestion
As mentioned here, the comparison itself is done by the fantastic dir-compare library which implemented with node's fs module

@gliviu I wonder if there is an easy way to supply dir-compare the "fs module" to use for comparing.
I thought maybe to create my own comparator as described in the docs but it feels overkill (it uses internal dir-compare module which I should also copy / implement) for replacing the fs module. What do you think?

[gbrueckl]

I just had a (very) quick look at dir-compare and it seems using the options to pass in specific functions to e.g list a directory or read a file could be a potential option
though, I am not sure how much work this requires internally
if we just need to ensure that the list-directory function (as an example) that we pass in via options has the same signature as the one from the fs module, I am sure I could provide this based on vscode.fs

I'd be very happy to support here if necessary.
I could also provide a mock-up extension that creates a virtual filesystem using a custom filesystem provider for easy testing

[moshfeu]

Thanks
An option to pass a function to getting the list sounds great, I couldn't find it, only a function for implementing the entire comparison, which is indeed require more work. Can you point me to that option?

Any support would be much appreciated 🙏

[gliviu]

Hello. A little bit late, but here are my thoughts.

dir-compare uses the native 'fs' module, and having it use the VSCode FileSystemProvider will indeed require some kind of wrapper.
However, FileSystemProvider is very different from fs and lacks many of its functions.

For reference, this is the fs functionality used by dir-compare:
fs.readdir()
fs.realpath()
fs.lstat()
fs.access()
fs.readlink()
fs.open()
fs.read()
fs.close()
fs.exists()
stat.isDirectory()
stat.isSymbolicLink()
stat.isFile()
stat.size()
stat.mtime()

Most of these functions are not difficult to emulate.
More problematic are the open/read/close() that work on a file descriptor.
The wrapper will have to map the FileSystemProvider.readFile() functionality over the fs.open/read/close. This will involve keeping a list of file descriptors and using them to know what file to read from.
In this context, issues might arise for large files when performing async comparisons, as FileSystemProvider reads the entire file into memory and the async comparison can work with many files simultaneously.

In addition to that, dir-compare will have to be changed to use a provided 'fs'-like module. This involves passing the module in the options and updating the codebase to use options.fs instead of fs itself.

And perhaps the most difficult task is testing the whole implementation in all kinds of scenarios.

From my point of view, if @gbrueckl wants to give it a try, I can provide the options.fs implementation.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.