You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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...
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?
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.
Activity
saschanaz commentedon Jun 1, 2017
Similar to the one discussed on #3152
saschanaz commentedon Jun 1, 2017
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...Clarify documentation on NODEFS that it does not replace MEMFS altoge…
juj commentedon Jun 5, 2017
Thanks, updated the documentation in the above commit.
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
FSobject altogether and writing aRAWNODEFSor 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?saschanaz commentedon Nov 26, 2017
I think a potential
RAWNODEFSstill should coexist with currentFSto keep supporting non-node environments.Initial NODERAWFS implementation (#6008)