memfs doesnt seem to work with mem.createWriteStream,
should it?

thanks

• https://github.com/mafintosh/fuse-bindings

Steps to reproduce :

1. fs.mkdirSync('/dir');

2. fs.writeFileSync('/dir/file.ext');

3. fs.readFileSync('/dir/file.ext');
   //returns Buffer[]

4. fs.renameSync('/dir/file.ext', '/dir/newfile.ext');

5. fx.readFileSync('/dir/newfile.ext');
   // Throws Error

Error: ENOENT: no such file or directory, open '/dir/file.ext'

Even though new file name is entered in readFileSync, it still tries to look for the old file?

Implement reflinks for copy-on-write functionality.

Hopefully this isn't a nightmare to track down.

var memfs = require('memfs');
var mem = new memfs.Volume;
mem.mountSync('/a', {});
mem.mkdirSync('/a/b/');
mem.mkdirSync('/a/b/c/');
mem.writeFileSync('/a/b/c/d.stuff', 'wat');
console.log(mem.readdirSync('/a'));

Outputs:

[ 'b', 'bc' ]

• Review Node.js recent changes to error messages
• Replicate Node's error messages
• Refresh and strip unnecessary parts from /internal/errors.js

Hi,
I'm playing around with memfs,union and linkfs. Pretty nifty.
But I often get errors when using some standard fs functions, especially with async function with callback.

I often get things like:

method readdir args { '0': '/sage2users/', '1': [Function] }

node_modules/unionfs/index.js:72
args = [].slice.apply(args, 0); // Convert arguments to Array.
^
It seems to always be that line...
Any ideas?
thanks.

_

When I use patchfs in fs-monkey, requires break.

I want to patch fs so that I can run some tests which use fs and fs-extra...but I still need to be able to require.

Maybe I should use patchFs with the unionfs filesystem of memfs and native fs?

Currently the published package doesn't contain any .d.ts files although this library is written in TypeScript.
It would help a ton if declaration files were available as it's way easier to use within other TypeScript projects.

I don't quite understand why the build process needs gulp, typescript and babel. Wouldn't TypeScript suffice to compile all src/**/*.ts files to lib and also emit declaration files?

the memfs.watch() function doesn't seem to work on directories. The following code works as expected:

var fs = require('fs');
if (fs.vol) fs.vol.fromJSON({ '/tmp': {}});
var fswatcher = fs.watch('/tmp', console.log);
fs.writeFileSync('/tmp/test.file', 'test data');
fs.unlinkSync('/tmp/test.file');
setTimeout(() => {fswatcher.close()}, 500);

Producing the output:

rename test.file
change test.file
rename test.file

but change it to use memfs instead::

var fs = require('memfs');
if (fs.vol) fs.vol.fromJSON({ '/tmp': {}});
var fswatcher = fs.watch('/tmp', console.log);
fs.writeFileSync('/tmp/test.file', 'test data');
fs.unlinkSync('/tmp/test.file');
setTimeout(() => {fswatcher.close()}, 500);

and I get no output.

EDIT: Changed the test code to be a little simpler and make the two cases much closer to each other with only a single line change.

I've started using this library for writing tests for my fs operations and I'm starting to notice some shortcomings of this library. Namely,

• Nodes can never be detected as symlinks using lstat. This makes testing fs logic dealing with symlinks, well, impossible.
• If a node exists, the error thrown does not conform to standard Node System Errors, making it hard to write logic that works with both the native fs module and memfs.

I initially opened up a PR to fix one, but realized that this project was written in TypeScript, which I haven't worked with yet.

I tried installing TypeScript and compiling and was greeted with errors about missing type definitions and whatnot. I've already run npm install, but I think the type definitions are out-of-date or not configured correctly. As the last activity on this repo was 8 months ago, I think there might have been some drift in the interim.

Anywho, I'd love to make some contributions to this repo, but I can't afford to take the time trying to reverse-engineer the dev setup. Mind adding some dev instructions to the README so I can skip to making PRs?

I am a little confused on how and when to use memfs, unionfs, linkfs, patchFs, patchRequire, jest-plugin-fs etc.

There are a lot of pieces to make a great vehicle but the instructions on how assembling them together are not well organized. A lot of documentation is sparse across different repos and issues on those repos. Outdated info in old issues and changes in the state of the art make the matter even more complicated.

I suggest adding a "Use cases" or "How to" section in the README.md.

Some points that I suggest to cover:

• Using memfs with jest. It seems that jest-plugin-fs is a quick drop-in replacement
• Using memfs with mocha.
• Replace tests on a filesystem with memfs. I am working on an old repo that creates a tree from fixtures in a ./tmp folder to run tests. I tried a few combinations of unionfs, linkfs, patchFs, etc. and I still have not been able to make it work as I want.

Adding a reference to these use cases in other repos would also help people to find them.

On github project release page, latest is 2.6.2. The package.json on master branch is 2.7.2. While I run npm install memfs I got 2.8.0.

The BigInt type in the Stats.d.ts file causes TypeScript to throw a 2304 (cannot find name) error, so the compilation fails.

TypeScript 2.8.3
memfs 2.14.1

memfs version: 2.6.0
OS version: macOS High Sierra 10.13.2 (17C88)

fs.open with read flag fails on directory. Though Nodejs' fs module allows to "open" folder.

A short code snippet to reproduce the issue:

const fs = require('fs');
const path = require('path');

const memfs = require('memfs');

const vol = new memfs.Volume();
const dir = path.resolve(process.cwd(), 'open-test');
vol.mkdirpSync(dir);
const fsmem = memfs.createFsFromVolume(vol);

fs.open(dir, 'r', (err, fd) => {
    console.log('fs', err);
});

fsmem.open(dir, 'r', (err, fd) => {
    console.log('memfs', err);
});

produces the output:

fs null
memfs { Error: EISDIR: illegal operation on a directory, open '/Users/kirilknysh/Projects/memfs-open/open-test'
    at createError (/Users/kirilknysh/Projects/memfs-open/node_modules/memfs/lib/volume.js:105:17)
    at throwError (/Users/kirilknysh/Projects/memfs-open/node_modules/memfs/lib/volume.js:114:11)
    at Volume.openLink (/Users/kirilknysh/Projects/memfs-open/node_modules/memfs/lib/volume.js:716:13)
    at Volume.openFile (/Users/kirilknysh/Projects/memfs-open/node_modules/memfs/lib/volume.js:748:25)
    at Volume.openBase (/Users/kirilknysh/Projects/memfs-open/node_modules/memfs/lib/volume.js:752:25)
    at Immediate.<anonymous> (/Users/kirilknysh/Projects/memfs-open/node_modules/memfs/lib/volume.js:623:39)
    at runCallback (timers.js:672:20)
    at tryOnImmediate (timers.js:645:5)
    at processImmediate [as _immediateCallback] (timers.js:617:5) code: 'EISDIR' }

Why to open directory? Sometimes, to ensure that a new file is created and exists in directory listing - fsync on parent directory must be called. Some details could be found https://www.quora.com/When-should-you-fsync-the-containing-directory-in-addition-to-the-file-itself .

I can't seem to figure if we can use this to create persistent storage inside an electron app for the duration that the app is running? From what I can tell the state is gone upon a page refresh.

Maybe I'm missing a piece of the puzzle, I'm still kind of new to electron, but it seems to me this should be possible. For what it's worth, I'm using the electron-vue framework.

Any help/pointers much appreciated!

After upgrading to the latest version (2.5.8), reading directories (in my case by using readdir) does no longer work properly.

I did a bit of debugging, and found out that the path separator is wrong (\ instead of /) which leads to paths not getting split correctly (they don't get split into steps at all, to be particular). A few hours later I discovered this PR (#50) which got merged a few days ago. Before this PR (version 2.5.7) everything works as expected, the latest version including the PR (version 2.5.8) does no longer.

Seems to me that, in order to get the correct separator, we check whether posix exists on the path module (see https://github.com/streamich/memfs/blob/master/src/volume.ts#L21), but we still use the separator from the normal path module instead of path.posix (which contains the correct separator).

I'm don't have that much experience with NodeJS tooling, but might it be possible that there is some bug here?

Hello!

First, thank you for your package. I am a Node.js beginner and memfs helps me a lot with testing and mocking.

I am developing a package to load configuration alphabetically by filenames. Searching for Node.js fs readdir behavior, I just realize this method is always sorted on Linux, but not on Windows (or filesystems, whatever).

nodejs/node#3232

https://nodejs.org/api/fs.html#fs_fs_readdir_path_options_callback
http://man7.org/linux/man-pages/man3/readdir.3.html#NOTES

Thinking about it, currently, I can't simulate a readdir with unsorted filenames in memfs.

https://github.com/streamich/memfs/blob/master/src/volume.ts#L1486

Can we improve some configuration to disable that feature, or implement another sort?

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

Invalid npm token.

The npm token configured in the NPM_TOKEN environment variable must be a valid token allowing to publish to the registry https://registry.npmjs.org/.

If you are using Two-Factor Authentication, make configure the auth-only level is supported. semantic-release cannot publish with the default auth-and-writes level.

Please make sure to set the NPM_TOKEN environment variable in your CI with the exact value of the npm token.

Good luck with your project ✨

Your semantic-release bot 📦🚀

I'm trying to use it with Node's promisify...

const fs = require( 'memfs' ); // Works with require( 'fs' );
const util = require( 'util' );

( async function() {
	const writeFileAsync = util.promisify( fs.writeFile );
	const readFileAsync = util.promisify( fs.readFile );
	try {
		await writeFileAsync( 'foo.txt', 'bar' );
		const data = await readFileAsync( 'foo.txt' );
		console.log( data.toString() ); // bar
	} catch ( err ) {
		console.log( err );
	}	
}() );

but I'm getting the following errors:

Error: ENOENT: no such file or directory, open 'foo.txt'
    at createError (node_modules\memfs\lib\volume.js:105:17)
    at throwError (node_modules\memfs\lib\volume.js:114:11)
    at Volume.openFile (node_modules\memfs\lib\volume.js:755:17)
    at Volume.openBase (node_modules\memfs\lib\volume.js:765:25)
    at Volume.writeFileBase (node_modules\memfs\lib\volume.js:987:23)
    at Immediate.<anonymous> (node_modules\memfs\lib\volume.js:623:39)
    at runCallback (timers.js:800:20)
    at tryOnImmediate (timers.js:762:5)
    at processImmediate [as _immediateCallback] (timers.js:733:5) code: 'ENOENT'

The same code works with node's fs. Am I doing something wrong?

The problem

Our app React state has grown cumbersome, 200kb in size. Even with encoded serving it's still 80kb which is still a burden for 3g devices.

The solution?

I realize a real solution would be only serving the state we need for a particular route, but due to the shoddy old architecture, it would require a complete rewrite of some things. I was wondering if it's possible to do something like this:

{/*
  1. Somehow store state in memFs
  2. Read it through jsx <script> tag
*/}

<script
  type="application/javascript"
  href={ linkToMemFSStateFile }
/>

The issue with an endpoint is that it needs to be a unique state for every user. I'm just pulling my hair out how to cut these 80kb of app state out because recently performance has been a big deal for my company, out of nowhere, when I've been previously stressing to revamp our route/state architecture so we don't have to do patches like this, but here we are.

Implement fs Pomise API

• https://nodejs.org/api/fs.html#fs_fs_promises_api

• https://github.com/nodejs/node/blob/master/lib/internal/fs/promises.js

  • Promises API
    • FileHandle
      • appendFile(data, options)
      • chmod(mode)
      • chown(uid, gid)
      • close()
      • datasync()
      • fd
      • read(buffer, offset, length, position)
      • readFile(options)
      • stat()
      • sync()
      • truncate(len)
      • utimes(atime, mtime)
      • write(buffer, offset, length, position)
      • writeFile(data, options)
    • access(path[, mode])
    • appendFile(path, data[, options])
    • chmod(path, mode)
    • chown(path, uid, gid)
    • copyFile(src, dest[, flags])
    • fchmod(filehandle, mode)
    • fchown(filehandle, uid, gid)
    • fdatasync(filehandle)
    • fstat(filehandle)
    • fsync(filehandle)
    • ftruncate(filehandle[, len])
    • futimes(filehandle, atime, mtime)
    • lchmod(path, mode)
    • lchown(path, uid, gid)
    • link(existingPath, newPath)
    • lstat(path)
    • mkdir(path[, mode])
    • mkdtemp(prefix[, options])
    • open(path, flags[, mode])
    • read(filehandle, buffer, offset, length, position)
    • readdir(path[, options])
    • readFile(path[, options])
    • readlink(path[, options])
    • realpath(path[, options])
    • rename(oldPath, newPath)
    • rmdir(path)
    • stat(path)
    • symlink(target, path[, type])
    • truncate(path[, len])
    • unlink(path)
    • utimes(path, atime, mtime)
    • write(filehandle, buffer[, offset[, length[, position]]])
    • writeFile(file, data[, options])

The following code throws RangeError [ERR_INVALID_FD]: "fd" must be a positive integer

var memfs = require('memfs');
var tty = require('tty');

var fd = memfs.openSync('/test', 'w+');
var stream = new tty.WriteStream(fd);

This is because the generated file descriptor number exceeds the range of positive integers (32-bit) which causes it to be considered a negative integer.

I believe the problem is in the Volume class, where the static fd variable is defined. It is initialized with 0xffffffff when it should be 0x7fffffff.

I'm a bit unclear why appendFile will add a new file but writeFile will throw an error instead of creating the file like the node fs will. Is this an oversight or intended behavior?

I have tried to test this in the browser by cloning the example webpack repo linked in the readme. Unfortunately when I run it I encounter the following error Uncaught TypeError: Cannot read property 'sep' of undefined.

It looks like memfs has a dependency on path, or a path-like library that prevents it from being used in the browser. Are you aware of any modules that can be used to fix this?

Hi.

https://travis-ci.org/deepsweet/copie/jobs/396571967

Works fine with Node 8 and 10.

I’m trying to use memfs in tests. Use case is like this:

1. Mock fs with memfs:

   // __mocks__/fs.js
   process.chdir('/');
   module.exports = require('memfs').fs;

2. Load the initial state from JSON using fromJSON method.

3. Run methods I’m testing.

4. Inspect the resulting JSON from toJSON.

The problem is that every time I call fromJSON it modifies the volume, keeping all existing files from previous tests.

I see two possible solutions:

1. Recreate a memfs volume before each test. Seems a bit too complex.
2. rm -rf / after each tests. But it seems scary — what if I forget to call jest.mock('fs')? ;-|

As a perfect solution I see fromJSON that can remove all existing files before loading JSON. Could be a new parameter or a new method.

What do you think?

Was comparing memfs and memory-fs and was failing a test. Discovered that memfs will create undefined directories when you fs.mkdirSync("/"); and that directory already exists.

// test.js
const {Volume} = require("memfs");

var fs = new Volume();

// snippet from https://github.com/webpack/memory-fs/blob/master/test/MemoryFileSystem.js#L18
fs.mkdirSync("/test");
console.log(fs.readdirSync("/"));
fs.mkdirSync("/test//sub/");
console.log(fs.readdirSync("/"));
fs.mkdirpSync("/test/sub2");
console.log(fs.readdirSync("/"));
fs.mkdirSync("/root\\dir");
console.log(fs.readdirSync("/"));
fs.mkdirpSync("/");
console.log(fs.readdirSync("/"));
fs.mkdirSync("/"); // <-- this should probably throw; creates an "undefined" folder instead
console.log(fs.readdirSync("/")); // --> [ 'root\\dir', 'test', 'undefined' ]

$ node test.js
[ 'test' ]
[ 'test' ]
[ 'test' ]
[ 'root\\dir', 'test' ]
[ 'root\\dir', 'test' ]
[ 'root\\dir', 'test', 'undefined' ]

I built a middleware for express that compiles the server's code for dev environments, it uses memfs presently, but the issue is when I require-from-string the compiler.outputFileSystem server file and that primary entry file tries to find a dynamic import(), it can't find that path based on webpack's output.path. It always checks for real paths (in my case /Users/dveremchuk/source/webpack4-react-new/lib/server/). I use '@babel/plugin-syntax-dynamic-import' to parse the import. I realize I can just convert the import to a deferred require, but I need to test things.

I tried rewriting node's Module._findPath() but that's a bit over my head now, and I didn't have time to dig into it.

Is it somehow possible to implement this with memfs/unionfs/fs-monkey?

Gist of what middleware is doing:
node_modules/my-custom-middleware/lib/main-middleware.js

const memoryFs = require('memory-fs')
const { vol } = require('memfs')
const join = require('memory-fs/lib/join')

client.compiler.outputFileSystem = new memoryFs()

// this actually gives me the error:
// TypeError: this.outputFileSystem.join is not a function (server)
// but I can "patch" it using memory-fs join

vol.join = join
server.compiler.outputFileSystem = vol

// later
// get main server entry file as serverFile
return new Promise((resolve, reject) => {
        webpackCompiler.outputFileSystem.readFile(serverFile, (err, buffer) => {
            if (err) {
                reject(err);
            } else {
                resolve(buffer.toString());
            }
        });
    })
// ERROR MODULE_NOT_FOUND
.then((source) => requireFromString(source, serverFile))

Test component I use:

import React, { Component } from 'react'

import('components/home')

export class App extends Component {
  render() {
    return (
      <div>
        Hello
      </div>
    )
  }
}

Error:

MODULE_NOT_FOUND: Cannot find module './home.js'
- loader.js:603 Function.Module._resolveFilename
    internal/modules/cjs/loader.js:603:15
  - loader.js:529 Function.Module._load
    internal/modules/cjs/loader.js:529:25
  - loader.js:657 Module.require
    internal/modules/cjs/loader.js:657:17
  - helpers.js:22 require
    internal/modules/cjs/helpers.js:22:18
  - server.js:708 Function.requireEnsure [as e]
    /Users/dveremchuk/source/webpack4-react-new/lib/server/server.js:708:25
  - server.js:86 Function.fn.e
    /Users/dveremchuk/source/webpack4-react-new/lib/server/server.js:86:40
  - app.tsx:12 eval
    webpack-internal:///./src/containers/app.tsx:12:21
  - server.js:796 Module../src/containers/app.tsx
    /Users/dveremchuk/source/webpack4-react-new/lib/server/server.js:796:1
  - server.js:689 __webpack_require__
    /Users/dveremchuk/source/webpack4-react-new/lib/server/server.js:689:30
  - server.js:60 fn
    /Users/dveremchuk/source/webpack4-react-new/lib/server/server.js:60:20

Webpack server config

module.exports = merge(base, {
  target: 'node',
  entry: [path.resolve(_root, 'src/server/server')],
  externals: [nodeExternals()],
  output: {
    path: path.resolve('lib/server'),
    filename: 'server.js',
    chunkFilename: '[name].js',
    hotUpdateMainFilename: 'hot-update-server.json',
    hotUpdateChunkFilename: '[id].hot-update-server.js',
    libraryTarget: 'commonjs',
  },
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        exclude: /node_modules/,
        loader: 'babel-loader',
        options: {
          babelrc: false,
          configFile: path.resolve(__dirname, '../babel/babel.webpack.node'),
          cacheDirectory: true,
          cacheCompression: false,
        },
      },
    ],
  },
})

Hey,
I'm having problems with windows and the realpath function.
It seems that the realpath function always returns the path in a unix format and not windows.

How to reproduce (on windows):

const {resolve} = require('path');
const {vol} = require('memfs');

process.chdir('/');

vol.writeFileSync('package.json', '');

const resolvedPath = resolve('package.json');
const realPath = vol.realpathSync(resolvedPath);

console.log(realPath); // '/package.json'
console.log(resolvedPath); // 'D:\\package.json'

What can I do?

Hi! Thanks for the great work!

Currently it doesn't build (click here for an example) unless I change the references from fs-monkey/lib/<blah> to fs-monkey/src/<blah>. (Click me) to see what I mean.

I’m trying to make it work with graceful-fs. And it tries to access fs.ReadStream.prototype:

https://github.com/isaacs/node-graceful-fs/blob/65cf80d1fd3413b823c16c626c1e7c326452bee5/graceful-fs.js#L165-L166

which doesn’t exist on memfs:

> const fs = require('fs');
undefined
> fs.ReadStream.prototype
ReadStream {
  open: [Function],
  _read: [Function],
  _destroy: [Function],
  close: [Function] }
> const memfs = require('memfs');
undefined
> memfs.fs.ReadStream.prototype
undefined

I can make it work by doing this change in index.ts:

-    fs.WriteStream = (volume as any).WriteStream.bind(null, vol);
+    fs.WriteStream = (volume as any).WriteStream;
-    fs.ReadStream = (volume as any).ReadStream.bind(null, vol);
+    fs.ReadStream = (volume as any).ReadStream;

But I assume it would break other things (though all tests are passing) otherwise you won’t do that.

const {fs} = require('memfs')
const realFs = require('fs')

realFs.readdirSync('/')
realFs.symlinkSync('/', '/foo')
realFs.readdirSync('/')
realFs.readdirSync('/foo') // works

console.log('works')

fs.readdirSync('/')
fs.symlinkSync('/', '/foo')
fs.readdirSync('/')
fs.readdirSync('/foo') // fails

https://runkit.com/vjpr/5a87383e1ff7740012733bd1

After updating to 2.x relative paths don’t work:

> const { fs } = require('memfs');
undefined
> fs.writeFileSync('f', 't');
TypeError: Cannot read property 'createChild' of null
    at Volume.createLink (/Users/sapegin/Dropbox/Projects/_Repos/mrm-core/node_modules/memfs/lib/volume.js:423:22)
    at Volume.openFile (/Users/sapegin/Dropbox/Projects/_Repos/mrm-core/node_modules/memfs/lib/volume.js:690:29)
    at Volume.openBase (/Users/sapegin/Dropbox/Projects/_Repos/mrm-core/node_modules/memfs/lib/volume.js:698:25)
    at Volume.writeFileBase (/Users/sapegin/Dropbox/Projects/_Repos/mrm-core/node_modules/memfs/lib/volume.js:927:23)
    at Volume.writeFileSync (/Users/sapegin/Dropbox/Projects/_Repos/mrm-core/node_modules/memfs/lib/volume.js:952:14)
    at repl:1:4
    at ContextifyScript.Script.runInThisContext (vm.js:44:33)
    at REPLServer.defaultEval (repl.js:239:29)
    at bound (domain.js:301:14)
    at REPLServer.runBound [as eval] (domain.js:314:12)
> fs.writeFileSync('/f', 't');
undefined

I'm trying to do a simple test:

const memfs = require('memfs');
memfs.fs.writeFileSync('/watson.json', JSON.stringify({
	"ocorrencia_id": 9001
}));

And, instead of writing things to the file, I'm getting this error:

TypeError: Cannot read property 'createChild' of null
	at Volume.createLink (C:\Temp\teste-watson\watson-orchestrator\node_modules\memfs\lib\volume.js:382:22)
	at Volume.openFile (C:\Temp\teste-watson\watson-orchestrator\node_modules\memfs\lib\volume.js:641:29)
	at Volume.openBase (C:\Temp\teste-watson\watson-orchestrator\node_modules\memfs\lib\volume.js:649:25)
	at Volume.writeFileBase (C:\Temp\teste-watson\watson-orchestrator\node_modules\memfs\lib\volume.js:878:23)
	at Volume.writeFileSync (C:\Temp\teste-watson\watson-orchestrator\node_modules\memfs\lib\volume.js:903:14)
	at client.query.then.res (C:\Temp\teste-watson\watson-orchestrator\populate\populate.js:37:12)
	at process._tickCallback (internal/process/next_tick.js:109:7)

In fact, all of the examples are giving off this error.

Hi! This is a question, close at any time if this is not the right platform. Is there any way to keep the memfs instance of a file/volume alive on a process that is closed and then opened again?

An example would be to write a "Mocked" file on first run, and when the process runs the next time, the file is available.

I'm trying to get a ftp server running with memfs (using: https://github.com/nodeftpd/nodeftpd).

nodeftpd at some point tries to read from fs:
var rs = self.fs.createReadStream(null, {fd: fd});
which fails by memfs with:

TypeError: path must be a string or Buffer
at pathToFilename (C:\projects\ftpproxy\node_modules\memfs\lib\volume.js:292:19)
at class_1.FsReadStream (C:\projects\ftpproxy\node_modules\memfs\lib\volume.js:1844:17)
at new class_1 (C:\projects\ftpproxy\node_modules\memfs\lib\volume.js:462:31)
at Volume.createReadStream (C:\projects\ftpproxy\node_modules\memfs\lib\volume.js:1739:16)
...

Any suggestions on how to solve this? I think the null-Argument at createReadStream freaks memfs out :-D

mock-fs supports a nested structure and represents empty dirs as empty objects.

At present I am using the flat module to take a nested structure into fromJSON, but there seems no way to create dirs without dummy files.

This is amazing and works really well for testing because it allows you to mock the filesystem while falling back to the actual filesystem when a path hasn't been mocked, especially for requires:

ufs
  .use({ ...fs })
  .use(vol)

But there doesn't seem to be a way to add a file in memfs so that it is mocked and doesn't fall back to the actual filesystem (so it will not be overwritten when tests run) but also does not show up as existing when calling something like fs.existsSync('foo.txt'). I would like to propose allowing a user to set a path to something, maybe undefined, to achieve this:

// foo.txt resolves when performing the lookup but still throws an error when being read 
// as if it doesn't exist.
const vol = Volume.fromJSON({ 'foo.txt': undefined })  

If you use undefined, you'll have to be careful not to run into the specification of a directory using null that you added today (thanks again).

I hope this doesn't sound too much like an edge case. I think it's pretty important for use in testing.

Hi,
I'm trying to use memfs as well as unionfs and linkfs with webpack replacing memory-fs.

So far, I had two issues, which are actually not directly related to memfs though.

• unionfs doesn't pass mkdirp, although memfs implements it.
  webpack requires mkdirp and my workaround is to patch it:

ufs1.mkdirp = (...args) => ufs1.asyncMethod('mkdirp', args);

• when using with linkfs (node's fs behind it), unionfs fails with unsupported mkdirp, instead of calling back an exception which is an expected behavior.
  it seems like a bug in https://github.com/streamich/unionfs/blob/5580150f2faf88276bff205b84ae70684823c30e/src/union.ts#L77

if (func) func.apply(fs, args);

or something like this helps my case.

I could try preparing a PR, but I'd leave it for now as you might have a better design choice.

Thanks for your great work!

Build script tsc -p . && cpy src/internal lib/internal copies also the error.ts file which subsequently gets then published causing the typescript projects to break.

Script could be enhanced with:

tsc -p . && cpy src/internal lib/internal && rm lib/internal/error.ts 

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: undefined. Note: this is a nested preset so please contact the preset author if you are unable to fix it yourself.

Actually it also contains

• demo
• .vscode
• docs
• .*rc
• *.json
• *.yml

It only needs all the mandatory files like README, package.json, LICENSE and lib/*.js + lib/internal/*.js

const { fs } = require('memfs')
fs.existsSync('pizza')

Expected result:

false

Actual result:

Error: ENOENT: no such file or directory, stat 'pizza'
    at createError (/Users/sapegin/Dropbox/Projects/_Repos/mrm-core/node_modules/memfs/lib/volume.js:95:17)
    at throwError (/Users/sapegin/Dropbox/Projects/_Repos/mrm-core/node_modules/memfs/lib/volume.js:104:11)
    at Volume.statBase (/Users/sapegin/Dropbox/Projects/_Repos/mrm-core/node_modules/memfs/lib/volume.js:1066:13)
    at Volume.existsBase (/Users/sapegin/Dropbox/Projects/_Repos/mrm-core/node_modules/memfs/lib/volume.js:1123:23)
    at Volume.existsSync (/Users/sapegin/Dropbox/Projects/_Repos/mrm-core/node_modules/memfs/lib/volume.js:1126:21)
    at repl:1:4
    at ContextifyScript.Script.runInThisContext (vm.js:44:33)
    at REPLServer.defaultEval (repl.js:239:29)
    at bound (domain.js:301:14)
    at REPLServer.runBound [as eval] (domain.js:314:12)

How do you feel about being able to specify directories in .fromJSON()? It might look like:

const vol = Volume.fromJSON({
  '/foo': {}
})

I think this would be a little easier than using mkdirp when you have multiple directories that need to be created.

webpack/webpack-dev-middleware#366 (comment)

memfs does not handle win32 paths starting with C:\ (unless you are actually on a windows machine). Probably not on your roadmap but it's a blocker for a personal pipe dream of replacing memory-fs with memfs.

const {vol} = require('memfs')
// treated as relative
vol.mkdirpSync("C:\\test")  // <-- creates a folder in my current working directory.
console.log(vol.toJSON())
// { '/Users/username/my-test/C:\\test': null }

const {vol} = require('memfs')
// treated as relative (and throws errors as expected)
// https://github.com/streamich/memfs/blob/master/docs/relative-paths.md
vol.mkdirSync("C:\\test"); // <-- throws Error: ENOENT: no such file or directory
vol.mkdirSync("C:\\"); // <-- throws Error: ENOENT: no such file or directory

By comparison, memory-fs treats paths starting with a / as probably posix and starting with [A-Z]: as probably win32. In the examples above, the presence of C: would be enough to convince memory-fs that it was an absolute win32 path.

memory-fs has no support for relative paths and throws if it encounters one. The relative path compromise that memfs makes is probably preferred as it's more similar to what fs does. But in the case of a win32 path prefix, memory-fs makes the more flexible choice.

FWIW, on my machine (a Mac), the following works exactly as memfs does. I don't know what it does on a Windows machine.

const fs = require('fs')
// treated as relative
fs.mkdirSync("C:\\test") // <-- creates a folder in my current working directory.

Hi there. The README.md says 100% of Node's fs API is implemented, but I can't find copy or copyFile in the API status markdown file or in the object I'm getting at runtime. Is this a bug?

toJSON only show the file is still exists