[Bug]: Potentially bug in fs/promises implementation when accessing asar file

[jarrodek]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a bug report that matches the one I want to file, without success.

Electron Version

17.0.0

What operating system are you using?

Windows

Operating System Version

Windows 11

What arch are you using?

x64

Last Known Working Electron version

n/a

Expected Behavior

fs.stat, fs.access, fs.readFile, fs.copyFile, and fs.readdir from the module fs/promises to return the corresponding values according to NodeJS documentation.

Actual Behavior

While calling any of the listed above functions on a packaged application that references a file that is inside the app.asar file it always throws an error

| Error: ENOENT: no such file or directory, stat ...

Testcase Gist URL

No response

Additional Information

After upgrading my application to Electron 17 and starting using the promises API for Node's FS module my users stated reporting bug reports with my application. After several hours of investigation, I realized that there are two issues. Firs one was related to the fs-extra library and more precisely to the graceful-fs library that incorrectly is passing null to the fs.* functions in some situations. After discovering this issue, I decided to implement some of the functions of fs-extra I commonly use. I used the fs/promises module in the implementation. I eventually realized that all functions that access files in the ASAR file throw errors instead of returning the corresponding value. Errors are always about a file not being found.

In the next step, I started debugging the packaged application and the IO process with the Chrome inspector. I set breakpoints in the lines that are executing fs/promises APIs. At a breakpoint, I tied to use the synchronous API from the fs module. These calls succeeded. However, the promise-based calls failed. Therefore I suspect there is an implementation bug for fs/promises module.
Note, this is not happening when using the same fs/promises APIs when accessing files on the filesystem (outside the ASAR file).

I hope it is enough description to start an investigation.
Regards

[codebytere]

Thanks for reporting this and helping to make Electron better!

Because of time constraints, triaging code with third-party dependencies is usually not feasible for a small team like Electron's.

Would it be possible for you to make a standalone testcase with only the code necessary to reproduce the issue? For example, Electron Fiddle is a great tool for making small test cases and makes it easy to publish your test case to a gist that Electron maintainers can use.

Stand-alone test cases make fixing issues go more smoothly: it ensure everyone's looking at the same issue, it removes all unnecessary variables from the equation, and it can also provide the basis for automated regression tests.

I'm adding the blocked/need-repro label for this reason. After you make a test case, please link to it in a followup comment. This issue will be closed in 10 days if the above is not addressed.

[bavulapati]

I've tried to reproduce this issue locally on both windows, mac. This could not be reproduced. Here is the gist I've tried to reproduce with https://gist.github.com/250dc4158d191dd3f2b2284cf9373c5c

const { access } = require('fs/promises');
const { constants } = require('fs');
const path = require('path');

app.whenReady().then(async() => {
  try {
    await access(path.join(__dirname, 'main.js'), constants.R_OK);
    console.log('can access file inside asar');
  } catch (err) {
    console.error('cannot access file inside asar', err);
  }
  try {
    await access(app.getPath('home'), constants.R_OK);
    console.log('can access file outside asar');
  } catch (err) {
    console.error('cannot access file outside asar', err);
  }
  app.quit();
})

The other scenario the reported issue of `ENOENT` can happen is when the actual file is missing.
@jarrodek Can you check if this gist represents the issue reported? If not, you can provide another gist

[github-actions]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. If you have any new additional information—in particular, if this is still reproducible in the latest version of Electron or in the beta—please include it with your comment!

[github-actions]

This issue has been closed due to inactivity, and will not be monitored. If this is a bug and you can reproduce this issue on a supported version of Electron please open a new issue and include instructions for reproducing the issue.