webtorrent / fs-chunk-store Goto Github PK

This is probably the issue, but it is not fully confirmed, as we didn't trace it exactly to this module.

In WebTorrent Desktop, there's a bug where a zero length file is not being created on the filesystem, which causes the mod-time code to think the file has been modified on disk and reverify the entire torrent.

Happens consistently with archive.org torrents.

cc @dcposch

I'm getting an eexists error when trying something similar to the below code, telling me the outputPath already exists:

const torrent = client.add(torrent, { path: outputPath });
torrent.on('done', () => {
  const readStream = torrent.files[fileIndex].createReadStream();
  fluent(readStream);
});

From what I can see on my filesystem, webtorrent has created the folder and added a single file to it, then errors when I later try to create a readstream from it. I was able to edit the copy of fs-chunk-store in my local node_modules folder, and reverting this change fixes the problem for me:

802dfa9

Node's docs say that { recursive: true } prevents EEXISTS errors, but maybe that doesn't count for the child most folder?

This line.
I am using webtorrent in my electron app, and getting an error because of it.
It seems to have been fixed in the current HEAD, but not in npm version.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update actions/cache action to v4
• chore(deps): update actions/checkout action to v4
• chore(deps): update actions/setup-node action to v4
• chore(deps): update dependency semantic-release to v23
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository