restic: self-update doesn't work on Windows

Could the claim that restic supports Windows please be removed until this and any other major issues with Windows support are fixed (or at least, put a big fat mention that it’s in Beta)?

Let’s not be overdramatic. restic backs up data on Windows well. There may be a few more bugs and a few missing features, but nothing major that prevents you from using it effectively on Windows.

Also, please don’t sidetrack this issue’s discussion.

I will just use a curl.exe command before restic to get the latest restic.exe from my internal network.

Ah, then rather use restic self-update --output temp-restic.exe, that’ll at least verify the authenticity of the binary. You can then move it to the right location manually.

The readme.md says “It supports the three major operating systems (Linux, macOS, Windows)”.

Could the claim that restic supports Windows please be removed until this and any other major issues with Windows support are fixed (or at least, put a big fat mention that it’s in Beta)?

Ah, then rather use restic self-update --output temp-restic.exe, that’ll at least verify the authenticity of the binary. You can then move it to the right location manually.

I think that something like that should be the default on all operating systems.

Currently, if you run restic self-update on linux, and it gets interrupted while it is running, you end up with a truncated and useless restic binary. It would be much better if the replacement of the old binary with the new is done via some sort of atomic operation.

Moving the running binary before writing the updated version in place version will indeed fix the issue. The running binary remains locked while running, but it can rename itself to something else. Since we have so many options, I’d like to get some input from the restic maintainers (@fd0 ?) before I submit a patch.

1. Do we want to change the behavior for all operating systems, or only for Windows? Renaming the binary may not be necessary on some non-Windows platforms, but it theoretically shouldn’t hurt either, and treating Windows separately will add code complexity.
2. Where do we want the old binary to go? Stay in program directory (renamed to .bak or something), moved to system temp directory, etc?
3. Do we want/need to handle clean up? Cleanup has to happen after the original version has exited, so there will need to be an out of band cleanup that can run on subsequent executions. Restic could always check for .bak files on startup, but this adds overhead and complexity. Moving to a temp directory arguably just puts the system in charge of cleaning everything up for us, although Windows isn’t always great at this.
4. Other thoughts?

Hi,

Can I suggest this library https://github.com/inconshreveable/go-update ? With go-update you can build self-updating Go programs and Windows is supported.