Timeout variable for retrying patch when process still open

[abenzick]

Feature request:

One thing I've learned from the logging is why the update always takes 30 extra seconds.

From the log file:

2022/09/22 20:11:20 ERROR 32 (0x00000020) Copying File C:\Users\aaronb\AppData\Local\Temp\tufup\AMP.exe
The process cannot access the file because it is being used by another process.

Waiting 30 seconds... Retrying...
        Older             62.8 m    AMP.exe
  1.5%
  3.1%
  4.7%

It seems like every time it starts the patch process it detects the app is still running, waits 30 seconds and then is able to patch.

Would it be possible to get a variable to set the timeout option so I can make it a little quicker than 30 seconds?

[dennisvang]

@abenzick Good point.

Background

The current implementation waits two seconds before starting robocopy. If this timeout is too short, robocopy will fail, and retry after a 30 second (default) timeout.

On my test systems the current "solution" seemed sufficient, but it is clearly very fragile.

Proposed solution

Apparently, robocopy also provides the option to set the retry-timeout: /w:<n> where n is in seconds

I'll see if I can incorporate this in the default install script.

Temporary workaround

In the meantime, a quick workaround would be to override the robocopy options, for example, you could pass the following arg to Client.download_and_apply_update(), to set the retry timeout to 2 seconds:

robocopy_options_override=['/e', '/move', '/v', '/w:2']

Those are just our default options, extended with the /w:2.

[dennisvang]

@abenzick Just released 0.4.2, which uses a 2 second retry-timeout for robocopy (instead of the default 30s).

In case someone wants to set a shorter/longer retry-timeout, the override described above can be used.