Currently, when calling `copyFileOut`, the original extension from the
file is lost, and a generic `*.tmp` is added instead.
This becomes problematic in the scenario where we use
`child_process.execFile` on a Windows Batch script that lives inside the
`asar` package.
Windows relies on the extension being present in order to interpret the
script accordingly, which results in the following bug because the
operating system doesn't know what do to with this `*.tmp` file:
```
Error: spawn UNKNOWN
```
Steps to reproduce:
1. Create a dummy batch script (test.bat):
```
@echo off
echo "Hello world"
```
2. Create an electron app that attemps to call this script with
`child_process.execFile`:
```js
var child_process = require('child_process');
var path = require('path');
child_process.execFile(path.join(__dirname, 'test.bat'), function(error, stdout) {
if (error) throw error;
console.log(stdout);
});
```
3. Package this small application as an asar archive:
```sh
> asar pack mytestapp app.asar
```
4. Execute the application:
```sh
> electron.exe app.asar
```
Consider an electron application that uses `execFile` to run a script
that lives within the application code base:
```coffee
child_process = require 'child_process'
child_process.execFile __dirname + '/script.sh', (error) ->
throw error if error?
```
An application like this will fail when being packaged in an `asar` with
an following error:
```
Error: spawn EACCES
```
Electron overrides certain `fs` functions to make them work within an
`asar` package. In the case of `execFile`, the file to be executed is
extracted from the `asar` package into a temporary file and ran from
there.
The problem is that during the extraction, the original permissions of
the file are lost.
We workaround this by:
1. Extending `asar.stat` to return whether a file is executable or not,
which is information that's already saved in the `asar` header.
2. Setting execution permissions on the extracted file if the above
property holds true.
Fixes: https://github.com/atom/electron/issues/3512
When the browser process is busy, calling webview.send (a method that appears
on its face to be non-blocking) will actually block, because most webview methods
are remoted to a guest view instance in the browser. Instead, define a few methods
which will instead send its call over an async IPC message.
