Rather than delete percentage complete, show it. Because we were hiding
percentage complete we were not aware of inaccuracies in the percentage
calculation that are introduced when you toggle blanking and
verification on various methods.
I could not find the original specification of this standard, although
many proprietary implementations exist (or claim to exist). Also there
are many 3rd-party descriptions of the method, which often differ in one
or another detail, but after some reading I could conclude that the most
likely definition should be as follows:
1. Fill the device with zeroes, do not verify.
2. Fill the device with ones, do not verify.
3. Fill the device with a PRNG stream, do verify.
In other words, this is a simplified version of nwipe's "dodshort".
Both display_help() and nwipe_options_parse() are consistent about the
--noblank option, in that it exists and has no short form. Make the man
page and nwipe_gui_noblank() indicate that correctly. Mention that "ops2"
never blanks the device regardless of the option.
Change code so that there is only one place where the log is flushed on
exit from the ncurses gui. Prior to this patch the flush was done twice
which resulted in duplicated lines and missing lines. The
log_current_element variable was being initialised after the first flush.
This caused subsequent writes to nwipe to write log_lines pointers passed
the end of the pointer array causing memory corruption and resulting in the
occassional segfault on attempts to print the log array.
This patch fixes a segfault that occurs when a logfile is specified.
The segfault occurred on exit of nwipe. It did not affect the wipe
process.
This patch also fixes a related issue, at the end of a wipe some
of the log lines were missing on stdout, this occurred when a log
file was not specified as an option.
As I did with ci.yml (ubuntu-latest) use apt-get update prior to installing system dependencies else CI will fail with missing dependencies when upstream versions change.
During testing a single drive two cores consistently run at close to 100%,
one core at 100% and the other varying between 80-100%. This shouldn't be
the case. Although there would be two threads running, i.e. the gui status
thread and the disk drives wipe thread I would have expected the amount of
CPU required to calculate the on screen stats to be insignificant as they
are only updated once a second.
To reduce the gui stats thread to near zero% while still maintaining the
stats update at one second I inserted an nanosleep interval of 100ms. This
now means that only the one core now shows at 80-100% while all other cores
are close to zero.
To avoid confusion, the master code should have the version number in the title bar. The version number shown in the master should be the version number of the next (unreleased version) followed by the suffix rc1. As an example, the current official released version is 0.26 so in the master title bar the version should be 0.27rc1, i.e. the release candidate for the proposed release 0.27.
