#158 Permission Issue: Default Bootstrap Location

[hinca]

Fixes #158.

[mordechaim]

At the first glance this seems good. I'll look deeper at it when I get around soon.

One slight concern, now that all updates end up in a shared folder I don't think it's safe to keep a constant name, as we might end up overwriting or installing someone else's update also found in that directory.

How about adding a unique string to the name, let's say, a Unix timestamp?
update4j-7301637301073.zip or update4j-2021-12-08T10:00:00:000Z

Edit: this is challenging, since we must be able to later find them for launchFirst installs

[hinca]

@mordechaim right... my understanding/intention was that this is only a temporary work file by nature and that the updates are eventually going to land in the basePath, which would be unique for every application... but this assumes we're running as updateFirst.

Of course, in case two updates were proceeding at the same time, it might make sense to differentiate them this way, i.e. by generating a String name from the baseUri - that should be unique for every product, right?

The launchFirst lifecycle is by definition tricky using a temp folder, since OS can just clean up files there as it sees fit, i.e. on Windows with Storage Sense you can have the temp folder cleaned up daily.

This would mean that for users with launchFirst, if the app starts once per day on login, it would never really be able to update.

The conclusion is that temporary folder is unsuitable for launchFirst update mode and should instead by placed somewhere more permanent, i.e. ~/.appname/update4j or %LOCALAPPDATA%/AppName/update4j.

[mordechaim]

How about adding another CLI option --archive [path] to the default bootstrap?

[hinca]

Sounds reasonable.