@noobian:
Funny that you mention this. After discovering this behavior in powerarchiver, I went into my other archivers (7-zip, WinRAR) and guess what? Same type of behavior in them with the formats that support the password field in their app! That made me suspect that this might be a problem with the underlying routines, and not the specific application. I hope it can be fixed soon. I’ve already informed WinRAR of the problem. Haven’t informed the 7-zip devs yet. Just got tired of typing ;)
And, yes this is a bug. Under no circumstances should an archiver corrupt an existing file, not to mention simply because the user enters the wrong password when trying to decompress a password protected archive into a directory that already contains a file with the same name.
Thanks for the responses.
yes, because we all use same 7zip engine, so same problem. Another problem is - even if we start using temp folder, how many people will turn it off because it is slower?
Because if you use current folder as temp option, it will always do this, it simply does not know that it failed before it extracts it. And if current folder is temp, then it will always overwrite file (with overwrite warning).
And again, it does show you the overwrite window, problem is that nobody cares about overwrite windows, people just click on Yes within same second it appeared :-).