Cannot decrypt important file

[Rector1]

I was trying out EncryptOnClick and somehow I encrypted in appdata/roaming/microsoft/clr security config/v2.0.50727.312, a file called security.config.cch

When I try to decrypt it, I'm told the file already exists and do I want to overwrite it.

If I say yes and try to do so, I am told: \AppData\Roaming\Microsoft\CLR Security Config\v2.0.50727.312\security.config.cch.EOC: Cannot access target file or folder. [113]

If I say no, I don't want to overwrite it and then try to decrypt, I am told: The file was not decrypted as it would overwrite an existing file.

I believe this is the only file encrypted.

I tried to do a system restore but it failed through "a catastrophic error" which is obviously something to do with the encrypted file as I've restored the system about six times previously without any problems.

I'd be grateful if anyone could offer some helpful advice.

(I have the correct password, by the way, this isn't a problem with a wrong or lost PW.)

[Dave Wilkins]

At a guess, Windows prevented it deleting the unencrypted version of the file (which it would normally do). You thus have an encrypted and unencrypted version in the same place. On the one hand, you try to decrypt over the top of the unencrypted file, and Windows stops you doing so (presumably for the same reason it prevented it being auto-deleted during the encryption stage). OTOH, if you say No when it prompts for overwrite, it cancels itself (there's not much else it can do).

If you copy or move the encrypted file to somewhere else (make an empty folder, maybe), it should decrypt fine, because there's no unencrypted version there to snarl things up. What you can then do with the result, I'm not sure. That's outside the scope of our support. The rules are probably known only to MS, given that it looks like that file is part of MS security config.

Moral: do not play with parts of the system. Use it for data you created...

[Rector1]

I tried a system restore a second time and it worked, fortunately.

Then although the file was still encrypted, to my surprise I found I was able to decrypt it when I tried again!

The problem arose late at night when I was dog-tired and clicked on the wrong file. I realised I'd goofed almost immediately but by then, alas, the file was encrypted. I shall double check anything I intend to encrypt in future.

Thanks for your reply and suggestion. I'd have tried it had I not lucked in a little earlier.

PS: Sorry about all the smiley faces but it's the first time I've tried them and I got a bit carried away.

[steward00]

Do what Winzip does, and prefill the password entry (and confirmation) field with the last-used password? Perhaps whether to do this should be a configuration option.