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

files are deleted after update #2181

Closed
ricaralan opened this issue Oct 10, 2017 · 11 comments
Closed

files are deleted after update #2181

ricaralan opened this issue Oct 10, 2017 · 11 comments
Labels

Comments

@ricaralan
Copy link

Hello everyone I build the installer with nsis ia32 arch, I use sqlite3 and everything works fine until the update is downloaded since it replaces all the files in the installation folder.
Then my database file is deleted, how can I prevent my database file from being deleted with the new versions?

electron-builder v19.33.0
electron-updater v2.10.1

thanks o/

@popod
Copy link
Contributor

popod commented Oct 11, 2017

@ricaralan do not store your db into your application folder ! This is a bad practice. Use by example the path given by let yourDbRootPath = app.getPath('userData'). For more informations, see this.

@ricaralan
Copy link
Author

ricaralan commented Oct 12, 2017

@popod thanks for your comment that is right and fortunately I could solve it yesterday and yes. It is very bad

I'll leave the stackoverflow link where there is also the solution plus my configuration code and again thanks

https://stackoverflow.com/questions/46677957/auto-update-files-are-deleted-after-auto-update

@sebheitzmann
Copy link

Hi, i'm surprised by this response. The nsis installer doesn't delete all file in the install folder, so why does the update do that ?
I have some log files in the install folder, some config files etc ... I'm surprised by this behavior.
Personnaly i found that keeping all the application in a single location is sometime a not so bad idea ( think about a portable version )

Is it a possibility to desactivate this behavior ? Or maybe list some 'conf' file like in a the Debian manifest file ?
It's not clear to me if it's a nsis behavior or electron-updater.

Thanks for any advise.

@develar
Copy link
Member

develar commented Oct 13, 2017

Application dir must be immutable due to security reasons.

@sebheitzmann
Copy link

ok, you're right. I will change my code. But just to know is nsis or electron builder ?

@develar
Copy link
Member

develar commented Oct 13, 2017

NSIS allows you to do whatever you want. It is electron-builder behaviour to ensure security.

@TheFeelTrain
Copy link

This behavior is extremely annoying for my use case.

I am developing the launcher for a game, so it downloads multiple gigabytes of files. I can't dump that much data into the AppData folder when the user specifically selected the install location to be somewhere else, such as a completely different (less full) drive.

It seems my only option would be to bundle the game and launcher together, but that creates a huge installer instead of the ~40MB one that is currently created. I don't want to use the web installer either as then it would be using that interface to download the game rather than the actual launcher.

Is there any other way to disable or get around it? Or at least explain what security concerns this causes. I don't understand what the issue is with being access its own folder...

@StarLucas
Copy link

I know that this is an old issue but took us a day from finding this thread to actually find the solution that was implemented 24 Feb 2017 - #1300

@gustavokei
Copy link

Hi, I know this is very old and there is a solution to it. However, I still have an issue... Every time my app updates and if the user has installed it in a custom folder ("allowToChangeInstallationDirectory" is set to true), it will download everything inside that folder.

To illustrate, suppose I have an app called "MyApp" and I install it in "C:/CustomFolder". When it gets updated, if the parent folder is not named "MyApp" (which is "CustomFolder" here), it will create a new folder "C:/CustomFolder/MyApp" and then it downloads everything there. It does work properly if the folder name is the same as productName set in package.json.

Here's what I have in my package.json:build
"build": { "win": { "target": "nsis-web", "requestedExecutionLevel": "highestAvailable", "icon": "build/icon.ico", "publish": [ { } ] }, "nsisWeb": { "oneClick": false, "perMachine": true, "allowToChangeInstallationDirectory": true, "deleteAppDataOnUninstall": true } }

And in my installer.nsh
!macro customRemoveFiles ${if} ${isUpdated} !insertmacro quitSuccess ${else} RMDir /r $INSTDIR ${endIf} !macroend

I am developing a launcher for a game as well, trying to achieve:

  • Install my app outside appdata
  • Keep one folder (that has the game files) after app gets updated

Any suggestions?

@NeekoGta
Copy link

I'm trying to achieve this too.
I want to keep folder in app directory when the app is updated (auto updater).

How can I use customRemoveFiles to exclude folder to be deleted ? Thank you ! :)

@LMJayasundara
Copy link

If you want to keep certain folders when updating an Electron app, you can use the asarUnpack field in the app's package.json file. The asarUnpack field specifies a list of glob patterns that match the files and directories that should be unpacked when the app is packaged as an ASAR (Atom Shell Archive).

For example, to keep the assets and node_modules directories when updating the app, you can add the following lines to the package.json file:

"asarUnpack": [
  "assets/*",
  "node_modules/*"
]

This will cause the assets and node_modules directories to be extracted to a separate folder when the app is packaged, and they will not be overwritten when the app is updated.

Note that the asarUnpack field is only used when packaging the app as an ASAR. If you are not using ASAR packaging, you can use a different approach to preserve certain directories during updates.

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

No branches or pull requests

9 participants