Consider Cleanup Operations

The crate currently does not attempt to clean up temporary files left behind in some circumstances. Situations where files could be left behind:

Unix:

• self_replace on Unix writes one temporary file next to the executable under a temporary name to support an atomic write. There is no API I'm aware of that would make it possible to avoid this issue.

Windows:

• In general all operations on windows can lose files, but in most cases those files are left in a temporary folder. Only if the temporary folder is not on the same value as the target exe, then files can be left over. In case a temporary folder cannot be used:
  • self_delete can leave both the current exe dangling (__relocated__) as well as the garbage collection binary (__selfdelete__)
  • self_replace has all the issues of self_delete but top of that the atomic write and rename file (__temp__) can be lost like on unix

For operations outside of a protected folder (self_delete_outside_path) the temporaries can be left in another location than the one of the executable.

All these losses are guarded and will only happen on killing the process or shutting down the machine.

Start by tracing the self_replace, self_delete, and self_delete_outside_path operations, including the relocated, selfdelete, and temp temporary names described in the issue. Compare the Unix and Windows failure cases, then define cleanup behavior for each guarded shutdown or process-termination scenario. Done means the listed temporary files are cleaned up where possible without breaking the existing atomic replacement and deletion operations.