Error: ENAMETOOLONG: name too long, unlink

[DanSallau]

For over a month today, i have being battling and trying to package my app with this amazing tool. However, all my effort failed. I have asked numerous question in SO , yet no solution among which is this http://stackoverflow.com/questions/37561851/electron-packaging-with-electron-packager.

After reading some blogs and suggestions. I moved my electron.js to my home folder . Now i am having the error below

I am running electron versions

 "electron-packager": "^7.0.3",
 "electron-prebuilt": "^1.2.1",

On my machine

Please i read somewhere some one was suggesting he solved his by building on his VM instead of the MAC machine. Does it really not work on MAC ? Previously, my build works for other platforms. However , it does not work for Darwin platform as you can noticed in my previous question on SO

http://stackoverflow.com/questions/37561851/electron-packaging-with-electron-packager . Someone suggested it was not building with my node_modules and i should move my electron.js to where my node_modules folder is available. Now i did moved it and i am getting the error above. Please how and what is wrong with my electron ? I have being trying this for over a month today. Any help would be appreciated.

[malept]

Clean out your output directories and try again. It seems you're hitting a copy recursion loop.

[DanSallau]

@malept thanks for the prompt reply. Please how do i clean my output directory ? Is there a command for that? I delete the tmp folders and the electron-packager folder all the time yet this error still persist. Please how do i clean my output dir.?

[malept]

I mean, remove the app-darwin-x64 directory.

After you do that, perhaps you should try to utilize the --out parameter (consult the docs for details).

[DanSallau]

I now changed my command to
electron-packager . Myapp --out ./electron --platform=darwin --arch=x64 --version=0.34.0 --overwrite.

The error is now gone. However . The issue here returns http://stackoverflow.com/questions/37561851/electron-packaging-with-electron-packager . It does not pack with the node_modules . Below are the only files i see in the folder

It throws the error below when i click the icon.

Please how do i solve the issue ?

[malept]

I would have to look to be sure, but I believe that you're specifying an Electron version that does not define the electron module. (In older versions, you had to require many features separately.) Look through the Electron release notes to see when they added the electron module, and then specify a valid version greater than or equal to that as the value of --version.

[DanSallau]

@malept thanks for your time sir. Have tried many versions, though couldn't find the article about the said module version. I read somewhere people where mentioning about package.js. I check my electron-prebuilt under node_modules. Inside there is package.json and i noticed something like below.

"_args": [
    [
      "electron-prebuilt@1.2.2",
      "/Users/nuru/git-repos/binary-next-gen"
    ]

My electron-prebuilt is "electron-prebuilt": "^1.2.1", though. I also notcied dependencies and devDependencies. I copied the dependencies under my main package.json unto my electron-prebuilt package.json. Still nothing change. My build returns 3 files on;y. None of y node_modules is compiled/built. I really am confused.

[malept]

It's Electron 0.35.0 that introduces the electron module.

Don't modify the modules in node_modules unless you know exactly what the consequences are. It's more than likely that will cause unexpected behavior that is difficult to debug.

[DanSallau]

@malept below is my project tree. Before, the electron.js you can see was inside src. I now moved it out . I can see any difference though.

My electron.js is below.

const electron = require('electron');
const app = electron.app;  
const BrowserWindow = electron.BrowserWindow;  // Module to create native browser window.

electron.crashReporter.start({
  productName: 'YourName',
  companyName: 'YourCompany',
  submitURL: 'https://your-domain.com/url-to-submit',
  autoSubmit: true,
});

var mainWindow = null;

app.on('window-all-closed', function() {
  if (process.platform != 'darwin') {
    app.quit();
  }
});

app.on('ready', function() {

  mainWindow = new BrowserWindow({width: 600, height: 500});
  mainWindow.loadURL('file://' + __dirname + '/../www/index.html',{"userAgent":"Mobile"});

  mainWindow.webContents.openDevTools();

  mainWindow.on('closed', function() {
    mainWindow = null;
  });
});

I read somewhere that someone suggested adding the line below

  mainWindow.webContents.executeJavaScript(`
    var path = require('path');
    module.paths.push(path.resolve('node_modules'));
    module.paths.push(path.resolve('../node_modules'));
    module.paths.push(path.resolve(__dirname, '..', '..', 'electron', 'node_modules'));
    module.paths.push(path.resolve(__dirname, '..', '..', 'electron.asar', 'node_modules'));
    module.paths.push(path.resolve(__dirname, '..', '..', 'app', 'node_modules'));
    module.paths.push(path.resolve(__dirname, '..', '..', 'app.asar', 'node_modules'));
    path = undefined;
  `);

right after mainWindow.loadURL . I tried it didn't help. Is there anything i may be doing wrong sir ? Note , my electron.js and its location/content.

[DanSallau]

@malept i works and packaged well for win32 .When i changed my command to
electron-packager . app --out ./electron --platform=win32 --arch=x64 --version=0.35.0 --overwrite

It packaged everything with a whole lot bunch of folders required yet it still does not package for Darwin version

[malept]

I would avoid naming your main file electron.js, because that's the same name as the module you're requiring.

What do you mean when you say it does not package for Darwin? Are you referring to your question in https://stackoverflow.com/questions/37561851/electron-packaging-with-electron-packager ?

[DanSallau]

@malept yup. I tried platform=win32 and it package with all the necessary folders and files. Only platform=Darwin thats not working. Only darwin is failing to package with the folders.

[malept]

The folders are there, they are just not shown in Finder. In OS X (or I guess as it's now called, macOS), when a folder has the suffix .app, it is considered to be a special folder that can be "executed" when you double-click it in Finder. If you want to see the contents of the app, either:

• use the command line, or
• in Finder, right-click (or hold down control and click) the application and select "Show Package Contents".

[DanSallau]

@malept thanks man . Really appreciate your time. You are right. 👍

[Billy-]

had to explicitly set --ignore=^.*electron-packager.*$ to stop this loop happening. Was building in a docker container so I'm guessing tmp directory wasn't set (setting --tmp=/tmp didn't change anything) and so current dir was used, leading to this copy loop. If this default behaviour of using the current directory as temp, should there also be a check if it conflicts with the source directory and therefore have a counter measure, such as creating a new directory in the current directory and automatically ignoring it?

[Billy-]

@malept can you comment on my logic above as to whether it might be correct and if so could this issue be re opened so you don't have to explicitly ignore this folder in order to avoid this copy recursion?

[malept]

In order to assess the problem further, it would be very helpful to have a minimal testcase to reproduce the recursion bug and test potential fixes. Using the electron-quick-start repository as a base, could someone please create a minimal Electron app that illustrates the issue as described, and post a link to it here? (With the appropriate steps to reproduce, of course.)

[Billy-]

@malept I forked the quick start repo and just added this one commit which adds electron packager as a dev dependency, adds the packager command as an npm script, and a docker compose file: Billy-/electron-quick-start@03ce719
You will need docker and docker-compose. Just checkout that commit and run docker-compose up. Word of warning, this will lock up your machine. Run in a VM.

[Billy-]

@malept Additionally I pushed this commit to bitbucket and ran it in bitbucket pipelines, you can view the log here: https://bitbucket.org/Billy-/electron-quick-start/addon/pipelines/home#!/results/%7B3bb09238-4a1d-485a-ad53-fdcdbf02f0a8%7D

[malept]

I finally found some time to look into this. I believe the problem is because the Docker image links /tmp to the same directory as your docker-compose.yml file. Since that is the same directory as your source files, it will recurse over the temporary directory that Electron Packager creates, /tmp/electron-packager, in an infinite loop until the ENAMETOOLONG error is hit.

To avoid this problem, I suggest setting --tmpdir=false whenever you use Electron Packager in a Docker container, which disables using the temporary directory as a staging ground.

[Billy-]

@malept Would it be possible to add in functionality to detect this issue and automatically prevent this from happening? It could add the temp directory in the working directory and automatically ignore it?

[malept]

It could add the temp directory in the working directory and automatically ignore it?

I think the heuristics for that are a bit convoluted. I think I would rather see someone submit a pull request to detect if they're in a (Docker?) container, and if that is the case (and tmpdir is not explicitly set), set tmpdir to false. There would need to be extensive tests written so that it doesn't affect non-container (and possibly non-Docker, if this is a Docker-specific behavior) usage.

[Billy-]

You'll have to forgive me as I don't know anything about how/why the temp directory is used. But I imagine if it's there it's there for a reason; what are the implications of disabling it?

Additionally I think this issue has the potential to occur in any environment, if the temp directory for some reason ends up in the same directory you are copying from (this can even be explicitly set). I think the heuristic should be quite simple; in pseudo code:

if (path_to_tmp_dir.indexOf(path_to_source_dir)) {
    ignoreFiles += tmp_files_regex
}

With this approach you don't have to worry about applying it only to one environment; it should be applied to any/all environments and it serves to prevent this issue from occurring only if it is going to occur.

Correct me if I'm wrong and I'll stop wasting your time 😛

[malept]

I also thought that pseudocode would work when I was investigating your example, except that it looks like Docker doesn't appear to do a hard link - I think it's a aufs mount or something. So it looks like a regular /tmp directory, but it's really the source directory. This is what I meant by convoluted heuristics.

[Billy-]

Ah, ok. Thanks for explaining. I will try to look into your suggestion.

[malept]

FWIW I managed to figure out a non-hacky solution to this problem, and it is in the 8.5.2 release.