Open PartialVolume opened 2 years ago
I forgot to mention that currently nwipe doesn't name the log file itself. So nwipe needs an option to create a named file itself.
If nwipe fails to read the S/N (which should be rare) or the drive doesn't have a S/N (buggy firmware anyone?) then that would require additional logic in the code. So I'd say MD5 is the better approach as that will always work. It would add 32 characters to the filename. Is there is an algorithm that can do shorter checksums?
Yes there is.
8-bit implementation (16-bit checksum) "abcde" -> 51440 (0xC8F0) "abcdef" -> 8279 (0x2057) "abcdefgh" -> 1575 (0x0627)
source: https://en.wikipedia.org/wiki/Fletcher%27s_checksum#Test_vectors (there is also some reference code there)
On Sun Solaris systems we used to use ascsum which produced 6 or 8 digit checksums. I don't know whether that's still in the Debian repositories, although as long as the code is small for the Fletcher checksum we could bring it into nwipe.
OR... just append a random 6 or 8 digit number generated from already build-in RNG (from either linux kernel or Mersenne).
/dev/urandom :)
When many hosts are running shredos/nwipe simultaneously and all uploading their nwipe logs and certificates to a ftp or sftp server the nwipe logs need to be unique as the log files may be ending up in the same directory. Two ftp transfers from different hosts that occur in the same second would result in corrupted, missed or overwritten files. Appending the md5 checksum of the log file to the log files name will overcome this rare problem. Alternatively just using the serial number of the first drive would also be sufficient.