Electron-builder: file permission errors in updater with 22.1.0

[Kilian]

• Version: 22.1.0
• electron-updater: 4.2

• Target: mac and windows

Both Mac and Windows seem to give issues updating because of file permissions (or timing?) using the above combination.

Mac:

Error: ENOENT: no such file or directory, rename '/Users/admin/Library/Application Support/Caches/polypane-updater/pending/temp-Polypane-2.0.1-mac.zip' -> '/Users/admin/Library/Application Support/Caches/polypane-updater/pending/Polypane-2.0.1-mac.zip'

Windows:

Error: EPERM: operation not permitted, open 'C:\Users\admin\AppData\Local\polypane-updater\pending\temp-Polypane-Setup-2.0.1.exe'

Followed by

Error: ENOENT: no such file or directory, rename 'C:\Users\admin\AppData\Local\polypane-updater\pending\temp-Polypane-Setup-2.0.1.exe' -> 'C:\Users\admin\AppData\Local\polypane-updater\pending\Polypane-Setup-2.0.1.exe'

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[Kilian]

it's still relevant.

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[BradleyDeLar]

It appears that after years of this issue being reported there is still no solution. Is that correct?

[ert78gb]

Hi @develar,

First of all, I don't like to comment on the closed issue, but it is still a problem on Linux AppImage and maybe on windows. I still have to investigate the windows issue.

I reviewed the AppImageUpdater.ts,FileWithEmbeddedBlockMapDifferentialDownloader and I recognised you use the fs-extra.close to close the file descriptor, but fs-extra.close is not gurantad the OS finished the I/O operations. See in close(2) documentation.

A successful close does not guarantee that the data has been
successfully saved to disk, as the kernel uses the buffer cache to
defer writes. Typically, filesystems do not flush buffers when a
file is closed. If you need to be sure that the data is physically
stored on the underlying disk, use fsync(2). (It will depend on the
disk hardware at this point.)

fs.fsync available in the node.js

I would like to suggest to use fs.fsync instead of fs.close. If you agree with me then I am opening a PR about it in the updater package.

In this case, we can fix chmod tries to run on file that not closed by the OS issue.

[ert78gb]

fsync is not a solution. I found the problem in our code.
The autoUpdater.autoDownload true by default. That's mean the download process starts automatically. If you also start the download manually it starts a new update and the 2 thread collide.
If you would like to start the update manually then set autoUpdater.autoDownload = false

[douglassllc]

We do set autoUpdater.autoDownload = false and use the autoUpdater.downloadUpdate() and still receive this error:

EPERM: operation not permitted, open 'C:\Users\<user>\AppData\Local\<app>-updater\pending\0-temp-<app>-win.exe'