Available disk space check

[joshtrichards]

For robustness as well as improved user experience we should consider adding proactive disk space availability checks in several spots[1] before proceeding with material disk using steps:

• at start (a general check for the prevailing then system requirement/recommended amount of available space before doing an update/upgrade: e.g. 2 x 1GiB or whatever)
• at start (a general check, based on the user's current installation, to make sure they have at least 2x their current installations space usage, excluding datadirectory, available)
• createBackup() (e.g. enough space before proceeding with the backup)
• downloadUpdate() (e.g. enough space for the download)
• extractDownload() (e.g. enough space for the extraction)

Possible checks might include one or more of:

• warn before proceeding with the step if disk space is lower than a baseline absolute number we consider necessarily to complete that step typically
• use real numbers where it's an option (e.g. we may be able to know the download size before we download, we may be able to calculate the space needed to perform the pre-update backup)

Things to consider:

• one check at the beginning isn't necessarily enough since systems are dynamic, but in some cases it's probably "good enough"

Benefits:

• better user experience through enhanced transparency, preventing execution of steps that are likely to fail, and elimination of partial updates
• lowered false bug reports (i.e. don't blame the Updater for local environment limitations)

[1] Or just one spot, at least to start, if we can cover something like 80% of the situations without needing new checks everywhere

[joshtrichards]

A single check would be fine, but we need to figure out a good number. We basically have three potential approaches:

1. A rough "general number" that is hard coded
2. Implementing some logic to assess the operator's specific installation requirements
3. Some real-time dynamic check where rather than worrying about how much space is needed overall, we just constantly check available space
4. Do nothing new (i.e. status quo) and continue to rely (and beef up if needed) error reporting from our various disk related activities

Obviously choice 1 is easiest, but it won't cover very real situations that choice 2 would: different apps in-place. We **can't ** (unfortunately) assume they're all just in custom apps folders that we'd be able to conveniently exclude from backups for example. So this means every environment will have very different backup space requirements. Choice 3 is interesting because it embraces that the system is dynamic and external events can change available disk space while we're running (but it's also more complicated).

If we pick too big of a rough number (choice 1) it'll warn/error out even in environments with minimal apps.

Related: Quota space (comes up in shared hosting) and effectively creates a full disk. Not sure we can reasonably detect this, but if we did we could easily overlay it over the handling we implement for disk space.

[joshtrichards]

Maybe a hybrid approach makes sense:

• Check for reasonable disk space availability at the start, warn if it seems low enough to be of concern - e.g.
  • Your available storage for { data_directory, installation_folder } is <2 GiB. Cautiously proceeding.
  • Your available storage for { data_directory, installation_folder } is <1 GiB. At least 1 GiB is required for use the Updater.

Also since the main variable between installations is going to be the app folders:

• Traverse and calculate their usage for real then add it to the others we can predict ahead of time