Thanks for your reply. I didn't find anything yet in the source suggesting I can disable JPEG writing. I'll keep following trunk evolution.
For new exciting stuff you'll want to follow the juciphox branch, but it's in the same svn repo so you probably already knew this. Anyway, what I was referring to wouldn't be in trunk, most of it's just odd bits of thoughts and discoveries here and there in different threads on the forums.
For FAT writing, yes, it's quite likely the usual operations will allow me to overwrite data on the card. I was wondering if someone did experiments to check that it is the case. I'll assume it's the case for the moment.
You can also assume nobody has experimented.
And please report back whatever you find...
It seems the best I can do is have CHDK periodically check for new files on the filesystem and encrypt them as we notice them, overwriting clear data with encrypted data. Not quite as secure as could be, but still a fun project nonetheless.
A periodical check thing might be dangerous if you press the power button (or the camera decides the batteries are empty) while your code is working, switching from rec to play could even be a problem?
Maybe you should start with a menu command to start the encrypter. This would also partially solve the problem of not being able to review the JPEGs for bad shots to delete in-camera or re-shoot (I'm saying partially, because you obviously don't want to use the Canon delete functionality because it doesn't overwrite).
All in all this is something that would greatly benefit from an in-camera customized photo browser (an old feature request); you could even review the encrypted images by supplying a key.
