Error creating file in .dev version: No file system handle registered

[markschaver]

Describe the bug

On a Mac, when I attempt to create a new file or open a daily note in the .dev version of Foam, I get an error message: No file system handle registered. I am using v0.26.1 of the extension.

Errors:

Command 'Foam: Create New Note' resulted in an error
Unable to write file '/markschaver/foamtest/Test.md' (Unavailable (FileSystemError): Error: No file system handle registered (/markschaver))

Command 'Foam: Open Daily Note' resulted in an error
Unable to write file '/markschaver/foamtest/2024-10-09.md' (Unavailable (FileSystemError): Error: No file system handle registered (/markschaver))

Small Reproducible Example

https://github.dev/markschaver/foamtest/blob/master/readme.md

Steps to Reproduce the Bug or Issue

1. Open repository in github.dev by clicking .
2. Use Cmd-shift-p to create a new file or open a daily note.

Expected behavior

I expect the files to be created. They are not. I am also unable to create new files by clicking on a wiki link.

Screenshots or Videos

No response

Operating System Version

macOS (though experienced same problem on Windows 11 with v26.)

Visual Studio Code Version

Latest .dev version.

Additional context

No response

[pderaaij]

Which browser are you using? And could you see if vscode.dev works?

[markschaver]

Chrome. And yes, vscode.dev works otherwise, including other extensions. I have used vscode.dev for a long time. It does not work either in Safari, where I get this error message:

Command 'Foam: Create New Note' resulted in an error
command 'foam-vscode.create-note' not found

[markschaver]

Tested at work on a Windows 11 machine, same result:

Command 'Foam: Create New Note' resulted in an error
Unable to write file '\markschaver\Notes\AnotherTest.md' (Unavailable (FileSystemError): Error: No file system handle registered (\markschaver))

Full URL: https://vscode.dev/github/markschaver/Notes. Same at https://github.dev/markschaver/Notes/.

Command 'Foam: Create New Note' resulted in an error
Unable to write file '\markschaver\Notes\StillAnotherTest.md' (Unavailable (FileSystemError): Error: No file system handle registered (\markschaver))

[pderaaij]

During my development work on this I only tested this on local folders. Doing some research it seems we need to add some capabilities to support remote repositories. See: https://code.visualstudio.com/blogs/2021/06/10/remote-repositories#_ensuring-your-extension-works-in-a-virtual-workspace

I will have a look at this in the upcoming weeks.

[pderaaij]

I've made some progress in this area. Will document my findings here. (@riccardoferretti FYI).

Ultimately, a re mote repository works as a virtual file system. This differs to the normal behaviour of Foam which in some areas looks at absolute paths or simply core functions that work differently. This requires us to handle some paths differently.

For example, the behaviour of workspace.findFiles() is different for local systems or virtual systems. For my test, I need to change the implementation as following:

const uris = await workspace.findFiles(
        folder.uri.scheme === 'vscode-vfs'
          ? '**/*'
          : new RelativePattern(folder.uri.path, '**/*'),
        new RelativePattern(
          folder.uri.path,
          `{${excludePatterns.get(folder.name).join(',')}}`
        )
      );

Note: Here I detect that the workspace folder is of the scheme vscode-vfs (virtual), if so, the include pattern should not consider the folder path (for my case here: /pderaaij/secondbrain). Locally this path is: /Users/paulderaaij/projects/secondbrain.

With this little change, Foam can load the graph and get most things working. However, Foam can't create files right now. I need to look into that behaviour, but will do with a fresh mind.

So, making some steps. However, I need some time to check some things before fully publishing a solution.

[riccardoferretti]

Mmmm... I am not sure, the folder there is coming from VS Code and it's one of the workspace folders, I don't understand how that would cause an issue. It is needed to support multi-folder workspaces (as opposed to opening a simple folder).
Am I missing something?

[pderaaij]

I am thinking RelativePattern causes the issue, but need to verify that.

[pderaaij]

So, did some digging into the way we use RelativePattern in workspace.findFiles. I started to look at the value of RelativePattern.baseUri when opening a local folder and a remote repository.

Locally: the baseUri is file:///Users/paulderaaij/projects/secondbrain. Which is correct with my local path and the right scheme: file.

Remote Repository: the baseUri is file:///pderaaij/secondbrain. Which is the correct path, but not the correct scheme. This should not be file, but vscode-vfs.

That is odd. So I've done some research and found out that RelativePattern accepts a WorkspaceFolder as argument in the constructor. Passing the folder allows RelativePattern to correctly construct the pattern. Changing the code of workspace.findFiles to the code below fixed this part of the issue, without if-else constructs.

const uris = await workspace.findFiles(
        new RelativePattern(folder, '**/*'),
        new RelativePattern(
          folder,
          `{${excludePatterns.get(folder.name).join(',')}}`
        )
      );

Resulting into the following baseUri for the remote repository: vscode-vfs://github/pderaaij/secondbrain

[pderaaij]

I've done some research on writing files, for example the daily note. The main issue here is that NoteFactory determines the new file path for the note. In doing so, we use the helper URI.file of Foams URI model. In doing so, we disregard the notion that schemes apart from file or placeholder exist. On the other hand, we would rather not check for the proper scheme everywhere.

So, I need some reflection on how to solve this. Especially as the only way to know if you are active on a virtual workspace is determined via the workspaceFolder. The initial thought I have is to set a flag on bootstrap of the project, which can be used in the URI model to return the proper scheme. But, open to suggestions here!

[riccardoferretti]

Thanks for the research @pderaaij - I will do a deep dive this weekend, I feel there are a few things I don't understand enough to give informed support. I am keen to keep to a bare minimum the difference between the code for the native and the web extension, and am willing to make some tweaks to the assumptions in Foam to make that happen (e.g. remove any support we might have for files that live outside the workspace). Let me have a think, and let me know if you have any update on your side as well, thanks!

[pderaaij]

The RelativePattern one is a safe one and won't impact that much. The NoteFactory change will be more impactful, but not sure if this is the proper way to go.

Regarding research. The most important thing is the structure of WorkspaceFolder the scheme attribute is essential in the process.

[pderaaij]

@riccardoferretti Would be great if you can have a look at it this weekend. Currently, I feel the best approach is to add an optional inContext argument to the URI.file. This allows us to not break all implementation, but also to separate the vscode-vfs concern away from the models in core. Example implementation could be:

/**
   *
   * @param value Creates an URI pointing to the given path of the file.
   *
   * @param inContext Can be used to point to the path in a given context. For example,
   *                  to be used for schemes other then 'file' e.g. 'vscode-vfs'
   * @returns URI object with path pointing to the given value.
   */
  static file(value: string, inContext: URI = undefined): URI {
    const [path, authority] = pathUtils.fromFsPath(value);

    if (inContext !== undefined) {
      return new URI({ ...inContext, path: path });
    }

    return new URI({ scheme: 'file', authority, path });
  }

Note: need to think about authority here. Requires some additional research.

We can then use it at the appropriate place. For example in createFromTemplate in NoteFactory

let newFilePath = template.metadata.has('filepath')
        ? URI.file(
            template.metadata.get('filepath'),
            URI.parse(workspace.workspaceFolders[0].uri.toString())
          )
        : filepathFallbackURI;

That ensures we give the vscode context to file in URI.

Please let me know what you think. I haven't put this into code for now. Just some prototyping.

[riccardoferretti]

Thanks for the write up @pderaaij - I have gone through your comments and the code, I think I roughly understand the problem. Before digging too deeply I wanted to reproduce the issue, and although I can see the problem in github.dev, I have been unable to reproduce the issue in other environments.
Specifically, even setting up vscode.dev and loading the extension there (basically following the instructions here: https://code.visualstudio.com/api/extension-guides/web-extensions#test-your-web-extension-in-vscode.dev) I still can't reproduce the issue - which makes it hard to assess ideas.
Where are you reproducing the issue? Am I missing anything?

[pderaaij]

You need the Github.remotehub extension. This allows you to open remote repositories. It is the same mechanism as vscofe.dev uses. See https://marketplace.visualstudio.com/items?itemName=github.remotehub&origin=serp_auto

So. I install this extension and then open a GitHub repo that I used for Foam.

[riccardoferretti]

@pderaaij I have looked a bit more at the issue.
The approach I would explore is staying within the URI realm in the context of the VS Code workspace.
Specifically, the function asAbsoluteWorkspaceUri turns a URI into a absolute file:// URI.
I don't remember if there was a good reason for this, but basically this is not necessary, as we could always live within the workspace.workspaceFolders context and therefore anything absolute is really just absolute in relationship to the workspace.
In other words, if making something absolute in the end boils down to a workspace.workspaceFolder[...].joinPath(...) you will alway get Uris that should be compatible with vscode-vfs.
What do you think?

[markschaver]

Great work. The issues I had are fixed except I still get an error trying to create a daily note:

[riccardoferretti]

Yeah good point, there are a couple of things in the command itself that need to be addressed as well

[pderaaij]

@markschaver do you have any specific settings for your daily journal? For example, the location? With the defaults it works in my situation. Would like to verify my hypothesis.

[markschaver]

No. My first thought was that I needed to set a directory for the daily note, but that didn't work either.

[riccardoferretti]

@pderaaij if I understand where you are going, I agree we will have an issue because currently we support templates outside of the workspace, and we will need to remove such functionality (unfortunate, but I feel there are workarounds, and having everything self-contained in the workspace is a stronger foundation).
In create-note we still have a couple of places where we use URI.file, those will need to go (and will require the change above).
Is that the direction you were heading towards? What's your thinking?

[pderaaij]

@riccardoferretti Not too concerned about templates outside the workspace, to be honest. The virtual file system is built around the root folder, and outside that root, it simply isn't part of the virtual file system.

I need to research a bit more, but a problem could be in the use of URI.toFsPath in dated-notes.createDailyNoteIfNotExists. Another potential problem could be:

const dailyNoteDirectory = asAbsoluteWorkspaceUri(URI.file(folder));

as used in dated-notes.getDailyNotePath. URI.file creates a scheme with file, which in the case of a virtual file system should be vscode-vfs. Thinking of it, this is most likely the biggest concern. Not sure, what the best solution is.

[pderaaij]

@markschaver I am having some trouble replicating the issue. This is what I do.

I go to my personal repository on GitHub. I press . and it will take me to the github.dev environment. This will automatically open a new daily note without any problem. Both in Firefox and Chrome.

What was necessary for me was to restart the extensions to make sure I had the latest.

Would you mind confirming if you have the latest version in your online environment? Furthermore, curious which browser you are using.

[markschaver]

I do the same, on Chrome (and Safari, though I'm unable to test it again at this moment but will later). I restarted the extension to make sure I had the latest (26.4). This is for a private repository, if that makes a difference.

[markschaver]

So, same result for me on Safari and Chrome on MacOS 15.1.1 and with Chrome on Windows 11.