Dynamic updates using getdown

[Tom Winterhalder]

Hello

In our company we are currently evaluating different products which should be used to update an installed and running software (new development in progress).

The following criteria are important to us:

1. check for updates (and update) on startup
2. check for updates and dynamic update while the program is running (periodically or upon user request)

Point 1 is covered by getdown. Is it also possible to call getdown from the running application and dynamically update the software (A short downtime to restart is allowed)?

Best regards,

Tom Winterhalder

[Michael Bayne]

On Wed, Aug 14, 2013 at 2:08 AM, Tom Winterhalder <tom.wint...@gmail.com> wrote:

The following criteria are important to us:

1. check for updates (and update) on startup
2. check for updates and dynamic update while the program is running (periodically or upon user request)

Point 1 is covered by getdown. Is it also possible to call getdown from the running application and dynamically update the software (A short downtime to restart is allowed)?

When running in versioned mode (which I assume you are), Getdown writes a version.txt file in the main app directory. From your app, you can fetch your getdown.txt file via HTTP, and check the version line in there against the version.txt file, and if the getdown.txt file is newer, you can initiate an update from within the app by writing the new version into version.txt and relaunching Getdown.

Getdown contains helper code to write the version file and relaunch, which you can use if you want to include getdown.jar in your app (or you can just use the ever effective copy and paste method):

    /**

     * Writes a <code>version.txt</code> file into the specified application directory and

     * attempts to relaunch Getdown in that directory which will cause it to upgrade to the newly

     * specified version and relaunch the application.

     *

     * @param appdir the directory in which the application is installed.

     * @param getdownJarName the name of the getdown jar file in the application directory. This is

     * probably <code>getdown-pro.jar</code> or <code>getdown-retro-pro.jar</code> if you are using

     * the results of the standard build.

     * @param newVersion the new version to which Getdown will update when it is executed.

     *

     * @return true if the relaunch succeeded, false if we were unable to relaunch due to being on

     * Windows 9x where we cannot launch subprocesses without waiting around for them to exit,

     * reading their stdout and stderr all the while. If true is returned, the application may exit

     * after making this call as it will be upgraded and restarted. If false is returned, the

     * application should tell the user that they must restart the application manually.

     *

     * @exception IOException thrown if we were unable to create the <code>version.txt</code> file

     * in the supplied application directory. If the version.txt file cannot be created, restarting

     * Getdown will not cause the application to be upgraded, so the application will have to

     * resort to telling the user that it is in a bad way.

     */

    public static boolean updateVersionAndRelaunch (

            File appdir, String getdownJarName, String newVersion)

        throws IOException

    {

        // create the file that instructs Getdown to upgrade

        File vfile = new File(appdir, "version.txt");

        PrintStream ps = new PrintStream(new FileOutputStream(vfile));

        ps.println(newVersion);

        ps.close();

        // make sure that we can find our getdown.jar file and can safely launch children

        File pro = new File(appdir, getdownJarName);

        if (mustMonitorChildren() || !pro.exists()) {

            return false;

        }

        // do the deed

        String[] args = new String[] {

            getJVMPath(appdir), "-jar", pro.toString(), appdir.getPath()

        };

        log.info("Running " + StringUtil.join(args, "\n  "));

        try {

            Runtime.getRuntime().exec(args, null);

            return true;

        } catch (IOException ioe) {

            log.warning("Failed to run getdown", ioe);

            return false;

        }

    }

-- m...@samskivert.com

[Anastasiia Petrych]

Hi Michael!

I cannot find any info on using OS permissions when updating an app.

In my company we want non-admin users to be able to update the application which is installed in a default system folder. Of course, non-admin users need to have admin permission to be able to update that app.

We're using install4j as an installer and want to use Getdown for auto-updates.

Do I assume correctly that using Getdown for updates will still prompt users for admin password?

On Wed, Aug 14, 2013 at 19:47:05, Michael Bayne wrote:

[Anastasiia Petrych]

Duplication of the previous post, now with added email

m...@samskivert.com

[Michael Bayne]

On Thu, Mar 7, 2019 at 7:24 AM Anastasiia Petrych <a.pe...@gmail.com> wrote:

Hi Michael!

I cannot find any info on using OS permissions when updating an app.

In my company we want non-admin users to be able to update the application which is installed in a default system folder. Of course, non-admin users need to have admin permission to be able to update that app.

We're using install4j as an installer and want to use Getdown for auto-updates.

Do I assume correctly that using Getdown for updates will still prompt users for admin password?

Getdown does not coordinate with Windows in any way to negotiate permissions to write files to system folders. I'm not familiar with how Windows handles this sort of thing, but I assume that what would happen if an app was installed in a system folder was that when the user ran it, it would try to write files using the privileges of the user that ran the app and it would fail.

Unless Windows is magically intercepting the request to write files to a system folder and automatically showing a privilege escalation dialog (which could prompt for an admin password), this is just going to fail completely.

As far as I know, people who use Getdown on Windows have the app installed in the user's local directory, where they have write permissions, rather than in a system directory. But if anyone has experience installing apps in a system directory, maybe they can respond to this email.

-- m...@samskivert.com

[Anastasiia Petrych]

Michael, thank you for your answer!