streamich/memfs

Discrepancy in close-after-unlink behavior

開放

#942 建立於 2023年8月18日

 (1 則留言) (0 個反應) (0 位負責人)TypeScript (147 個分叉)github user discovery
bughelp wanted

倉庫指標

星標
 (2,062 顆星)
PR 合併指標
 (平均合併 4天 8小時) (30 天內合併 8 個 PR)

描述

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)

貢獻者指南