Since Go 1.8 os.Executable is part of the stdlib, so osext can be dropped from the dependencies.

That change is not tested, because a test requires to create a s3 bucket and a fake binary. That said I'm confident because a recent change in osext invokes os.Executable if the library is compiled under Go 1.8.

Previously the still open executable file was directly written to, which caused the program to abort with a text file busy message on some systems.

Now the following approach is taken:

• Move the old file to a backup path
• Try to write to the original path
• If opening/writing the original path fails: Move backup to old location
• If upgrade is successful: Remove backup file

Based on https://github.com/exercism/cli/pull/290

Instead of copying the downloaded update into memory and then writing from memory to the final file, the reader for the download is used for buffered writing to the final file.

I tested it with a "hello world" program that compiles to a 10 MB executable and then using pprof to create a memory profile. For creating the profile I imported github.com/pkg/profile into the s3updater package and called profile.Start(profile.MemProfile).Stop() right before the os.Exit(0). I profiled the code multiple times and the resulting profiles weren't always the same, but each time the original s3updater code lead to at least 8 MB memory usage, while the code after my changes always lead to less than 110 KB. For example:

Original s3updater | After my changes -----------------------|------------------- |

I only used Go profiling a few times before and only CPU profiling, so maybe there's something wrong about this or it doesn't show the full picture of what's happening. But I also checked my PC's memory usage and the difference can be seen in the same way.

Now, 10 MB RAM is not a big deal. But some Go programs use packages like github.com/gobuffalo/packr (or one of its many alternatives that are compared here), so the file to update could be 100 MB or more. When running on a memory-constrained device like a Raspberry Pi Zero W (with only 512 MB RAM), this would be bad.

Additionally, in the original implementation the garbage collector doesn't know that it can release the allocated memory, because when s3udpater downloads the update and runs it, it blocks in cmd.Run() and data still references the downloaded bytes and the GC doesn't know if it will still be accessed or not. This means the memory usage isn't just high during the update, but for all remaining time the updated program is running. Maybe this can already be mitigated by moving the part with the download and file operations into a function, so the GC sees that there's no reference to the slice of bytes any more after the function returned. But that would still lead to the temporary high memory usage during the update. With the buffered write both is covered.

Let me know what you think :)

Instead of spawning child processes you should replace the parent process. You could do this by replacing the exec.Command block on line 156-177 with this line: syscall.Exec(os.Args[0], os.Args, os.Environ())

Related to exec: https://groob.io/posts/golang-execve/

Instead of moving current to a backup file, save download to temporary file.

This will prevent issue where update is cancelled by external factor, where we would not be able to move .bak to its original location.

Following DELIVERY-213 we didn't fixed the error

The argument passed to syscall.Exec (os.Args[0]) suppose relative binary will be found/resolved properly

It succeeded with ./releases/aww-darwin-amd64 and /usr/local/bin/aww but failed with path call aww

Using absolute destination enforce the absolute resolution and hence resolves the error for further releases

With the current implementation each update requiers the user to re-run the command.

This PR solves this by restarting the command automatically, so the user doesn't need to do anything except waiting for the process to complete 🤘

Currently, if something happen during the download process, the binary file is corrupted and need to be manually restored.

I propose doing a very simple verification by checking the downloaded file size after downloading has finished, then proceed.

Currently only tests for errors.

A test for a working update via S3 would require a mocked S3 that's being started and stopped from the test. I think that can be done, but maybe in a later PR.