Software installation best practices
When you've got critical settings files that absolutely should never be overwritten or cleared back to defaults, this pattern has always worked well for me. It can apply to both Windows, Linux and Mac based software.
The installation method can either be a simple file copy utility/archive or something more complex like a Windows installer.
An example target structure might look something like this:
/MyApplication
/bin => Application binaries.
/defaults => A default version of all settings files.
/docs => Documents or manuals.
/settings => Critical settings files.
The settings folder contains the critical settings files and is not part of the installer. The installer includes only the bin, defaults and docs folders. So installing the software only overwrites bin, defaults and docs, but never the settings. This applies equally to Windows installer packages - for this case, just don't include the settings folder in the Windows installer package. The defaults folder contains the default version of all of the the files expected in the settings folder.
Whenever the software accesses a particular file in settings the following lazy initialisation logic is used ...
- Does the settings folder exist?
- Yes: Continue
- No: Create the folder and continue
- Does the file exist?
- Yes: Open it
- No: Copy the file from the defaults folder into the
settings folder, then open it
By following the above logic, you ensure that an existing critical settings file is never overwritten.
From reading the latest report on the deadly Airbus A400M crash, its claimed that the cause was that their software installation procedure did the equivalent of overwriting a settings file or clearing it back to defaults. In this case, the settings file contained calibration parameters that were critical to the operation of 3 out of the 4 propeller engines.
Follow @dodgy_coder
Subscribe to posts via RSS
