Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

resources/app folder has broken permissions #402

Closed
jf908 opened this issue Jun 20, 2016 · 11 comments
Closed

resources/app folder has broken permissions #402

jf908 opened this issue Jun 20, 2016 · 11 comments

Comments

@jf908
Copy link

@jf908 jf908 commented Jun 20, 2016

The /resources/app folder can't be deleted because its permissions are somehow broken. I get this error either by trying to package as an asar or when trying to overwrite a previous build when using the Programmatic API with electron-packager installed locally in the folder.

{ Error: EPERM: operation not permitted, rmdir 'D:\user\appNameFolder\appName-win32-x64\resources\app'
  at Error (native)
  errno: -4048,
  code: 'EPERM',
  syscall: 'rmdir',
  path: 'D:\\user\\appNameFolder\\appName-win32-x64\\resources\\app' }

When I use command line using the global package.

EPERM: operation not permitted, rmdir 'C:\Users\User\AppData\Local\Temp\electron-packager\win32-x64\appName-win32-x64\resources\app'

After this error occurs, I can delete the app folder myself but I can't using the rmdir Windows command and it returns "Access is Denied". If I check the permissions through the properties window it has the same settings as any other folder. I'm not sure what's causing this error and I've tried investigating but haven't gotten anywhere so far.

I figured it might be problem with npm but I've tried reinstalling npm and nodejs multiple times to no avail.

After the error occurs once with the command line, using it a second time will cause no console output. This can be fixed by deleting the AppData/Local/Temp/electron-packager folder. It gets stuck here because it doesn't have permission to delete the app folder from the previous build.

Which version of electron-packager are you using?

7.0.4

What CLI arguments are you passing? Alternatively, if you are using the API, what parameters are
you passing to the packager() function?

for the packager() function

const options = {
    platform: 'win32',
    arch: 'x64',
    dir: '.',
    version: '1.2.3',
    tmpdir: false,
    asar: true,
    overwrite: true
};

for the command line

electron-packager . --platform=win32 --arch=x64 --version=1.2.3

Although I have tried many other options with no success.

What version of Electron are you building with?

Tried 1.2.1 and 1.2.3

What is the host platform are you running electron-packager on?

Windows 10 x64

What target platform(s)/architecture(s) are you building for?
win32 x64

Please provide either a failing testcase or detailed steps to reproduce your problem.
Installing it both globally

@malept
Copy link
Member

@malept malept commented Jun 20, 2016

I wonder if this is related to #375, despite not being on OSX?

CC: @jprichardson

@jf908
Copy link
Author

@jf908 jf908 commented Jun 20, 2016

It might be related but there are few differences. It still doesn't work using tmpdir=false. Also, I can delete it as a user but not through command line which is the opposite to that issue.

It's been working fine up until recently but I'm not exactly sure what triggered this.

@malept
Copy link
Member

@malept malept commented Jun 20, 2016

Try an earlier version of electron-packager?

@jprichardson
Copy link
Member

@jprichardson jprichardson commented Jun 21, 2016

Yeah, I don't think this one is related to #375. Windows has some funky delete issues at times - I'm not saying that's what's going on here, but I've ran into similar strange issues in the past related to these sorts of things.

Possibly related: isaacs/rimraf#105. Also, not the same error, but discusses more Windows related delete issues: isaacs/rimraf#72.

@develar
Copy link
Contributor

@develar develar commented Jun 21, 2016

Possible workaround: use asar: true.

Possible, because electron-packager still doesn't create asar directly from app, but copies and only then creates asar archive.

@jf908
Copy link
Author

@jf908 jf908 commented Jun 21, 2016

Thank you everyone for the help, I finally solved the issue even although I think it wasn't directly related to electron-packager.

I'm not sure how but the folder had been set to read-only. It took a while to realize this because I've never dealt with Windows permission issues before. Everything inside the folder was writable and setting it through the properties window had no effect.

I only found out that it was read-only by using ls in powershell and saw there was an r mode where there shouldn't be. I fixed the issue using the command attrib -R appNameFolder.

@jf908 jf908 closed this Jun 21, 2016
@jprichardson
Copy link
Member

@jprichardson jprichardson commented Jun 21, 2016

I'm not sure how but the folder had been set to read-only.

Yep, so it was the pesky isaacs/rimraf#105 then.

@jf908
Copy link
Author

@jf908 jf908 commented Jun 22, 2016

Yeah looks like it was something to do with that.

@binaryfunt
Copy link

@binaryfunt binaryfunt commented Sep 22, 2018

After getting this error, trying to repackage doesn't work (or do anything), even using --overwrite. Removing the read-only permission from the app folder as described above and deleting the %localappdata%/Temp/electron-packager/ folder then allows it to work next time

@binaryfunt
Copy link

@binaryfunt binaryfunt commented Oct 17, 2018

The trouble is, every time I run electron-packager, it creates a read-only folder resources/app/ and a tempdir with the same permissions, so the next time round I get the same problem again

@shockthetoast
Copy link

@shockthetoast shockthetoast commented Jun 4, 2019

@binaryfunt Are you using SVN for your project? I ran into this issues while using TortoiseSVN for the project.

Recently I tried moving the .svn folder out of my project, then runing attrib -r /d /s on the project root. After that I was able to build repeatedly. (Before that, I had to run the attrib every time, as you stated.)

If I then move the .svn folder back in, it still works. The only explanation I can think of is that TortoiseSVN doesn't like the .svn folder not being readonly, but it applies it in a way that affects the project folder. I'm really grasping at straws here, though.

At this point I am able to rebuild repeatedly without issue. Though if it is SVN, a project update may cause a regression. At the very least, I assume this would have to be done by anyone who checks out the project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.