open the names database and truncates it (thereby emptying it). If then calls a routine that may return an error if the name is not found in which case processing will quit but the file will be empty.
This has never been a problem before because the calling code was protected from calling this routine if the name did not exist, therefor that code path was never gone through.
In the SDK case, however, those protections do not seem to be in place because the file was emptied.
One solution would to protect against calling in in the caller, but then why is there a test for an error in the function? Another is to test for the presence of the name prior to desctructively opening the file which is what I'm going to do.
In fact, any place in our code where we destrcutively open a file, we should protect with a backup file first.
tjayrush
commented
3 weeks ago
This line:
https://github.com/TrueBlocks/trueblocks-core/blob/master/src/apps/chifra/pkg/names/delete.go#L26
open the names database and truncates it (thereby emptying it). If then calls a routine that may return an error if the name is not found in which case processing will quit but the file will be empty.
This has never been a problem before because the calling code was protected from calling this routine if the name did not exist, therefor that code path was never gone through.
In the SDK case, however, those protections do not seem to be in place because the file was emptied.
One solution would to protect against calling in in the caller, but then why is there a test for an error in the function? Another is to test for the presence of the name prior to desctructively opening the file which is what I'm going to do.
In fact, any place in our code where we destrcutively open a file, we should protect with a backup file first.