streamich/memfs

Discrepancy in close-after-unlink behavior

Open

#942 opened on Aug 18, 2023

 (1 comment) (0 reactions) (0 assignees)TypeScript (147 forks)github user discovery
bughelp wanted

Repository metrics

Stars
 (2,062 stars)
PR merge metrics
 (Avg merge 4d 8h) (8 merged PRs in 30d)

Description

The fs module accepts calls to FileHandle.close() when the underlying file no longer exists, while memfs throws ENOENT. I suspect this could be the root cause of #550 and #900.

Reproduction cases (ts-jest):

describe('memfs/fs parity', () => {
  const testPath = path.join(__dirname, 'my-test-file');
    
  it('fs does not error on close after delete', async () => {
    const f = await fs.open(testPath, 'w');
    await fs.unlink(testPath);
    await f.close();
  });

  it('memfs should not error on close after delete', async () => {
    const f = await memfs.fs.promises.open(testPath, 'w');
    await memfs.fs.promises.unlink(testPath);
    await f.close();
  });
});

Error message:

 FAIL  test/fs.spec.ts (5.259 s)
  ● memfs/fs parity › memfs should not error on close after delete

    ENOENT: no such file or directory, open '/Users/dolan/IdeaProjects/big-shuffle/test/my-test-file'

      at createError (node_modules/memfs/src/node/util.ts:138:17)
      at Volume.openFile (node_modules/memfs/src/volume.ts:684:38)
      at Volume.openBase (node_modules/memfs/src/volume.ts:696:23)
      at Immediate.<anonymous> (node_modules/memfs/src/volume.ts:516:25)

Contributor guide