In order to prevent manual changes to certain ini files on my test system, I currently store an MD5 checksum of the file to another file. This is a bit mess: two files for the price of one! I was thinking I could store the MD5 hash of the (text) file contents to the metadata of the file, but I don't know how to do this in LabVIEW. Perhaps there is a better solution. Thoughts?
You could write the checksum into the Registry. Find functions under Connectivity>>Windows Registry Access VIs.
In order to prevent manual changes to certain ini files on my test system, I currently store an MD5 checksum of the file to another file. This is a bit mess: two files for the price of one! I was thinking I could store the MD5 hash of the (text) file contents to the metadata of the file, but I don't know how to do this in LabVIEW. Perhaps there is a better solution.
Well you can't store the MD5 of a set of data...in the set of data that the MD5 is generated from. That would then change what the file's MD5 is, and make it invalid. There are a few work arounds that I was successful in testing and that was to generate an MD5 of the file ignoring the last line. Then I could store the MD5 in that last line, and when I go to check if the file has been edited, I can see if the MD5 of the file (ignoring the last line) is equal to the MD5 at the last line.
Storing in the registry is something that can be done, but most parts of the registry are read-only from the logged in user, unless you are an Administrator. Really you're just going to have to write an API for generating and MD5, and verifying the MD5, and there are many methods to make those two functions work, which might also include storing the MD5 file in a temporary, or app data folder.
Another option to protect your INI files is to encrypt them before saving them to the file system. You can find encryption VIs here:
Thanks for the great response! I actually just wrote a test VI to append the MD5 to the first line of the file (last line works too, of course). This required doing a checksum on the file contents, not the file itself. Which is fine. A custom API would be required. I like the portability of this solution (fewer files).
I wanted to keep the ini files human readable. They can be changed in a text editror, but my application checks for manual changes using the checksum and requires a password. But I do appreciate the encryption method. That would be a great way to go where the file didn't need ot be human readable!
When I had to do something similar to this, I had a single file that held the MD5 of all of the files that needed verified. I then put a CRC on the data in this file to catch people tampering with it. I was verifying 100s of files for this project, including source files.
I would avoid the registry since MS has flat out told developers to stop writing to it starting with Windows 7. They are locking it down more and more with each new version of Windows.