Packaging darwin build on Windows results in blocked folder (access denied)

[fourpixels]

Hi there,
I've just started using the packager, and it works pretty well. Thanks for the great work and the efforts here :)

I just have a problem with building for Mac on Windows. I use this line of code:

D:\work\www\droplet>electron-packager ./ Droplet --platform=darwin --arch=x64 -- version=0.33.9 --out=build

And the build was successful:

Packaging app for platform darwin x64 using electron v0.33.9
Wrote new app to build\Droplet-darwin-x64

But here comes the problem - I cannot archive or copy this build. When archiving with WinRAR, I get the following error:

!   D:\work\www\droplet\build\Droplet-darwin-x64.rar: Cannot open D:\work\www\droplet\build\Droplet-darwin-x64\Droplet.app\Contents\Frameworks\Electron Framework.framework\Libraries
    Access is denied.
!   D:\work\www\droplet\build\Droplet-darwin-x64.rar: Cannot open D:\work\www\droplet\build\Droplet-darwin-x64\Droplet.app\Contents\Frameworks\Electron Framework.framework\Resources
    Access is denied.

Followed by a 5 seconds wait time, and another like 10 errors for maybe all things in Frameworks folder.

I've managed to copy it through cmd, using xcopy, BUT the build was 50% larger (don't know why), and does not run on Mac: The application “Droplet.app” can’t be opened.

Do you have any ideas why this happens? Using Windows builds (on any arch) works like a charm! Any ideas will be appreciated!

[hacksalot]

+1. We ran into this issue a few weeks back and have been packaging OS X builds from an OS X build machine as a workaround. Access is denied seems to indicate an access or authorization issue but I suspect the root cause here is file/archive corruption caused by cross-building assets.

[malept]

I don't think any of the current active contributors have a Windows-based development environment, so a community contribution would be most appreciated.

[fourpixels]

I would love to do something about it, but I'll need some help as I don't know where to start from :) Any ideas or recommendations?

[max-mapper]

@fourpixels See if you can get the test suite to run on your Windows machine, just run npm test. If that works, maybe write a test that fails on windows?

[kfranqueiro]

From what I recall when I tested this (I run Windows 8 and tested on a win7 VM), you normally cannot even run electron-packager targeting darwin without admin privileges due to symlinks (which electron-packager detects and skips), and if you do run with admin privileges, yes, I've found it impossible to archive correctly without running into errors. I'm not sure if there's a way around it besides packaging for OS X on OS X or Linux.

To be clear, electron-packager itself shouldn't be resulting in an error AFAIK.

[matthiasg]

the links created arent real sym-links though (just shortcuts), so even if you pack the resulting folder with admin privileges it doesnt work on osx then.

[matthiasg]

It also seems to be the case that the fs.symlink calls are setup incorrectly. e.g when dumping the calls i get the following args:

[ 'c:\\Development\\Test\\electron\\Versions\\Current\\Mantle\\',
  'c:\\Development\\Test\\electron\\Giftnotruf-darwin-x64\\Giftnotruf.app\\Contents\\Frameworks\\Mantle.framework\\Mantle',
  [Function] ]

[ 'c:\\Development\\Test\\electron\\A\\',
  'c:\\Development\\Test\\electron\\Giftnotruf-darwin-x64\\Giftnotruf.app\\Contents\\Frameworks\\ReactiveCocoa.framework\\Versions\\Current',
  [Function] ]

where c:\\Development\\Test is my current working directory. The first parameter is the path to target to link to but those target folders dont exist. Even when i inject 'junction' into the parameters now (as would be helpful for windows (see https://nodejs.org/docs/latest/api/fs.html#fs_fs_symlink_destination_path_type_callback) it wont help obviously.

Where are these target folders supposed to be ? e.g Versions\Current\Mantle

[matthiasg]

this would seem to be related to #117

[lukeapage]

@matthiasg I am confused as to how it works on mac - the code used to unzip is extract-zip, which is JS only and therefore should be running the same on mac as on windows?

I don't know much about symlinking, so I experimented with some changes to extract-zip, but didn't get anywhere constructive..

• you are right about junction - because isDir is always false for the symlinks and one of them is a file and the other are directories
• One of the problems appears to me to be the paths - the link path is relative to the zip, but no opts.dir is joined on to it, so I don't see how link will ever be right
• Another problem is that the directories the symlinks are created in do not exist, so it needs to make those directories

I get this output:

creating symlink - "C:\test\build\macos\Electron.app\Contents\Frameworks\Electron Framework.framework\Electron Framework" to "C:\test\build\macos\Versions\Current\Electron Framework"
creating symlink - "C:\test\build\macos\Electron.app\Contents\Frameworks\Electron Framework.framework\Libraries" to "C:\test\build\macos\Versions\Current\Libraries"
creating symlink - "C:\test\build\macos\Electron.app\Contents\Frameworks\Electron Framework.framework\Resources" to "C:\test\build\macos\Versions\Current\Resources"
creating symlink - "C:\test\build\macos\Electron.app\Contents\Frameworks\Electron Framework.framework\Versions\Current" to "C:\test\build\macos\A"
creating symlink - "C:\test\build\macos\Electron.app\Contents\Frameworks\Mantle.framework\Headers" to "C:\test\build\macos\Versions\Current\Headers"
creating symlink - "C:\test\build\macos\Electron.app\Contents\Frameworks\Mantle.framework\Mantle" to "C:\test\build\macos\Versions\Current\Mantle"
creating symlink - "C:\test\build\macos\Electron.app\Contents\Frameworks\Mantle.framework\Modules" to "C:\test\build\macos\Versions\Current\Modules"
creating symlink - "C:\test\build\macos\Electron.app\Contents\Frameworks\Mantle.framework\Resources" to "C:\test\build\macos\Versions\Current\Resources"
creating symlink - "C:\test\build\macos\Electron.app\Contents\Frameworks\Mantle.framework\Versions\Current" to "C:\test\build\macos\A"
creating symlink - "C:\test\build\macos\Electron.app\Contents\Frameworks\ReactiveCocoa.framework\Headers" to "C:\test\build\macos\Versions\Current\Headers"
creating symlink - "C:\test\build\macos\Electron.app\Contents\Frameworks\ReactiveCocoa.framework\Modules" to "C:\test\build\macos\Versions\Current\Modules"
creating symlink - "C:\test\build\macos\Electron.app\Contents\Frameworks\ReactiveCocoa.framework\ReactiveCocoa" to "C:\test\build\macos\Versions\Current\ReactiveCocoa"
creating symlink - "C:\test\build\macos\Electron.app\Contents\Frameworks\ReactiveCocoa.framework\Resources" to "C:\test\build\macos\Versions\Current\Resources"
creating symlink - "C:\test\build\macos\Electron.app\Contents\Frameworks\ReactiveCocoa.framework\Versions\Current" to "C:\test\build\macos\A"
creating symlink - "C:\test\build\macos\Electron.app\Contents\Frameworks\Squirrel.framework\Headers" to "C:\test\build\macos\Versions\Current\Headers"
creating symlink - "C:\test\build\macos\Electron.app\Contents\Frameworks\Squirrel.framework\Modules" to "C:\test\build\macos\Versions\Current\Modules"
creating symlink - "C:\test\build\macos\Electron.app\Contents\Frameworks\Squirrel.framework\Resources" to "C:\test\build\macos\Versions\Current\Resources"
creating symlink - "C:\test\build\macos\Electron.app\Contents\Frameworks\Squirrel.framework\Squirrel" to "C:\test\build\macos\Versions\Current\Squirrel"
creating symlink - "C:\test\build\macos\Electron.app\Contents\Frameworks\Squirrel.framework\Versions\Current" to "C:\test\build\macos\A"

from the following code changes

            // AFAICT the content of the symlink file itself is the symlink target filename string
            function writeSymlink () {
              readStream.pipe(concat(function (data) {
                var link = data.toString()
                link = path.resolve('C:\\test', path.join(opts.dir, link));
                dest = path.resolve('C:\\test', dest);
                var destDir = path.dirname(link);
                mkdirp(destDir, function() {
                    debug('creating symlink - "' + dest + '" to "' + link + '"')
                    fs.symlink(link, dest, 'junction', function (err) {
                      if (err) {
                          debug(err);
                          cancelled = true
                      }
                      done(err)
                    })
                });
              }))
            }
          })

the arguments to fs.symlink are destination, path
it seems that the 2nd argument e.g. path is the symlink location and the 1st argument is the one that it points to.

so to pick one example
"C:\test\build\macos\Electron.app\Contents\Frameworks\Squirrel.framework\Resources" should be a symlink to "C:\test\build\macos\Versions\Current\Resources"

which makes sense because multiple things link to Versions\Current\Resources.

I assume that the only way it could work is when I write a file to the symlink folder, mac creates the destination path if it doesn't exist.

My code doesn't work, not sure yet why.

[lukeapage]

Looking at the very first entry, it writes the file and then creates a symlink in the location the file is at.. preusmably mac must copy the file to the symlinked location and then link to it.

I think all this symlinking quirks would have to be handled for us to get a mac distrib and even after we have done it, there is no guarentee that packaging up the windows symlinks will create an archive with the right format for mac :(

anyone else have any input or thoughts?

[Jevirs]

I'm running into the same problem too,the output folder cann't be zipped and not work on OS X

[jhovgaard]

Any news on this? I'm also stuck not able to get my app out for OSX? Is there any workaround?