Skip to content

Direct access to the OS filesystem #5266

Closed

Description

@saschanaz

The NODEFS is documented as a way to directly access filesystem, but it's limited because it should be used through FS.mount(). As a result the C code cannot easily access paths for other drives e.g. D:/image.png (on Windows) got from the user input. Is there another way to allow "direct access" to OS filesystem?

Currently I'm trying to port image encoder/decoder to Node.js wasm command-line tool by passing process.argv into callMain(). However, this limitation forces me to pre-parse the arguments and then convert the paths.

In addition, the root directory / is not really the root one in Windows (same as C:/), which means you need to manually enumerate all drives to mount them. This cannot be done on Node in a simple way and causes cross-platform compatibility issue.

Activity

  1. saschanaz commented on Jun 1, 2017

    @saschanaz
    CollaboratorAuthor

    Similar to the one discussed on #3152

  2. saschanaz commented on Jun 1, 2017

    @saschanaz
    CollaboratorAuthor

    I had to use some hack to solve this problem, but it has unexpected permission problem when accessing user directory e.g. C:/Users/username/Documents/. No idea why...

  3. juj commented on Jun 5, 2017

    @juj
    Collaborator

    The NODEFS is documented as a way to directly access filesystem, but it's limited because it should be used through FS.mount()

    Thanks, updated the documentation in the above commit.

    Is there another way to allow "direct access" to OS filesystem?

    Currently I'm trying to port image encoder/decoder to Node.js wasm command-line tool by passing process.argv into callMain(). However, this limitation forces me to pre-parse the arguments and then convert the paths.

    Unfortunately Emscripten's filesystem (library_fs.js) is hardcoded to only understand the Unix path names form, so it cannot reason about the form "C:/path/to/file.txt" at all. Mounting root directories under /mnt/c, /mnt/d, etc. like MSYS does is probably the best bet here.

    If one wanted to remove the whole virtual filesystem and replace it with direct mappings to node, then that would probably mean removing the FS object altogether and writing a RAWNODEFS or similar to fully replace this. That would mean that Emscripten would not maintain a filesystem at all, but only pass all filesystem operations through to node - though I'm not sure how much of a 1:1 correspondence these would have?

  4. saschanaz commented on Nov 26, 2017

    @saschanaz
    CollaboratorAuthor

    If one wanted to remove the whole virtual filesystem and replace it with direct mappings to node, then that would probably mean removing the FS object altogether and writing a RAWNODEFS or similar to fully replace this.

    I think a potential RAWNODEFS still should coexist with current FS to keep supporting non-node environments.

  5. added a commit that references this issue on Jan 16, 2018
    99e4fc3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions