Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test: File system provider API #35009

Closed
1 task
jrieken opened this issue Sep 26, 2017 · 8 comments
Closed
1 task

Test: File system provider API #35009

jrieken opened this issue Sep 26, 2017 · 8 comments
Assignees

Comments

@jrieken
Copy link
Member

jrieken commented Sep 26, 2017

Test for: #34218
Complexity: 4

We have added proposed API for file system provider. They allow you add a new root node to the explorer (currently implemented as adding a workspace folder), allow for file creation/discovery/saving etc.

For testing, write a file system provider. To keep things simple, I suggest to implement a "localhost"-provider, that represents files on your computer and uses the node API. A sample of an FTP provider is here: https://github.com/jrieken/ftp-sample. You are obviously free to take a more complex sample, like tar-files or ssh but at the risk of spending much time understanding how the backends work

  1. Note that you need to register your provider for a scheme and that your provider needs to provide a root
  2. Note that your extension needs to use a new (and undocumented) activation event which is onFileSystemAccess:<your_scheme>

This is feature ready and all done but the purpose is to that we have the right abstraction that allows you feed (remote) files into the editor.

  • Test that your root and its children show up and can be browsed
  • That that your provider isn't called like crazy
  • Test that you get called to modify files (contents, times, etc)
  • Test that your files feel like normal files but that certain operations (like reveal in finder) aren't available
@ghost
Copy link

ghost commented Oct 23, 2017

Would this feature allows editting files on a remote Linux server over SSH ?

I currently use vscode remote extension, but it's limited to only a single file at a time

@khimaros
Copy link

khimaros commented Oct 23, 2017

The API certainly allows for this, but @jrieken's ftp-example extension only implements FTP.

I have a functional prototype of SFTP support built using the ssh2-sftp-client lib. Just working on some usability improvements. I intend to release it in the next few days.

@ghost
Copy link

ghost commented Oct 23, 2017

Thanks sftp sounds good.

I presume that I would need to write a bit of code ( golang for me ) to match the client API ? Or if it just using standard sftp command ?

@khimaros
Copy link

The comment about FTP support is in reference to @jrieken's ftp-filesystem extension. I'll update this bug with a link to my SFTP repo once it's up.

@ghost
Copy link

ghost commented Oct 23, 2017 via email

@ghost
Copy link

ghost commented Oct 23, 2017

I will expose it on the remote server with this. It supports serving files automatically.

https://github.com/pkg/sftp

It will make it very easy for users on any OS to try out.

@khimaros
Copy link

@gedw99 -- there may be a misunderstanding. The proposed API referenced in this bug allows for filesystem extensions to be written for any backend (ftp, sftp, webdav, etc are among the possibilities).

The sftp-filesystem extension I mentioned allows you to edit files in vscode directly over an SSH2/SFTP connection as though they were local files.The only setup required is to have an SSH server on the server which hosts the files.

If you are authoring something like a debugger extension for vscode, there is a separate mechanism for accessing the file contents.

@ghost
Copy link

ghost commented Oct 23, 2017 via email

@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 17, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants