midenup saves the installed files directly into the user's filesystem. This means that, if an install gets stopped mid-way through, the filesystem is in an incomplete state. So, we take measures (such as logging) to figure out in which state the channel is in, in order to continue the install from there.
However, this means that various parts of the codebase (namely, uninstall.rs) have to contemplate the possibility of an incomplete install, which adds complexity.
This could be mitigated if installs where made atomic (meaning, the install is either fully installed, or not installed at all; no "incomplete" state). This could be achieved with the following changes:
- Instead of installing the channel directly into the "final destination", it could be stored into a temporary "work directory" (that could either live in the OS's
tmpfs of inside the midenup directory itself).
- Once the channel is installed, we rename this "work directory" to the chanell's real name. If I'm not mistaken, the
rename operation is atomic (at least in POSIX).
- Afterwards, we update the manifest as usual. There is a bit of and edge case regarding the window of time between renaming the directory and updating the manifest, however this is something we already take into account.
Codewise the changes are fairly minimal: the main change would happen in install.rs where we would create this work directory and execute the install into it. The install script itself would have basically no changes.
With this, we could remove the .installed_components and installation-successful logic from uninstall.rs (as it would only be used in install.rs). Adittionally, we could also remove the channel.json file entirely and rely solely on the local manifest for uninstall.
midenupsaves the installed files directly into the user's filesystem. This means that, if an install gets stopped mid-way through, the filesystem is in an incomplete state. So, we take measures (such as logging) to figure out in which state the channel is in, in order to continue the install from there.However, this means that various parts of the codebase (namely,
uninstall.rs) have to contemplate the possibility of an incomplete install, which adds complexity.This could be mitigated if installs where made atomic (meaning, the install is either fully installed, or not installed at all; no "incomplete" state). This could be achieved with the following changes:
tmpfsof inside themidenupdirectory itself).renameoperation is atomic (at least in POSIX).Codewise the changes are fairly minimal: the main change would happen in
install.rswhere we would create this work directory and execute the install into it. The install script itself would have basically no changes.With this, we could remove the
.installed_componentsandinstallation-successfullogic fromuninstall.rs(as it would only be used ininstall.rs). Adittionally, we could also remove thechannel.jsonfile entirely and rely solely on the local manifest for uninstall.