Avoiding Accidental File Corruption

[czardas]

Hopefully this should be an easy enough question. I intend to make a file as difficult as possible to tamper with accidentally. Any data corruption will prevent the script from working. The file will be made available to the script for writing purposes but the end user mustn't touch it. I don't expect there will be any watertight solutions for this, but so far I have thought of the following options.

1. Set file properties to read only

2. Set file properties to hidden

3. Remove the file extension.

4. Create a backup copy elsewhere. on disc (Hmm: not portable)

5. Password protected zip archive (Hmm: may require 3rd party software)

Perhaps a combination of options 1 to 3 will be good enough, but maybe someone has done something like this before and has a better solution. Any suggestions will be appreciated. Gracias!

[MvGulik]

Kinda mystified about the 'tamper' and 'accidentally' use in your text.

Depending on your target user. The hidden and read-only option are nice for the computer idiot's type of user. But for the more advanced computer user there completely useless. (for the crack-hat kinda users there is of course no watertight solution.)

What is there to protect ?

[czardas]

It's really intended for idiots who ignore the Read Me file and lose all their encrypted data by some unknown method (which is normally the case if they start to experiment with things). Third party software could also be to blame. It's not intended to cover all possible scenarios. Viewing the file is fine, but editing is out of the question (except by the script of course).

I would also like the app to be portable, otherwise option 4 would probably be good idea. Someone using a shared computer might alter the file, not knowing what it is: perhaps a younger relative.

Edited October 13, 2011 by czardas

[MvGulik]

In that case Hidden and Read-only are fine (although read-only would do in my view). As additional feature you could add a options to auto-backup the file to a secondary location. With that, I think, that you as developer have done your job.

If a user bypasses a Read-Only setting on a file without taking note of the documentation. That's his choice ... and problem if things go wrong.

[czardas]

With that, I think, that you as developer have done your job.

That's a good point. I just wanted confirmation or if anyone knew some magic trick.

[SkinnyWhiteGuy]

Hashes were made to compute a value from input, and if any small amount changed in that input, the hash changes drastically. You could hash the encrypted data, and store the hash either in the same file, or elsewhere. That would make it a little more idiot-proof for tampering, since they'd have to know to re-hash the data, and put the hash back.

There's more than could be done besides encrypting, like compressing or putting it through base64. Just depends on how many idiots you are trying to be protected from.

[czardas]

Thanks for the suggestions. Now that you remind me, I should take a deeper look at the hash functions by Trancexx.

[jvanegmond]

Set read-only as an indicator for users trying to change it, and make md5 of the file and compare it to a known checksum in code.