THE SSL CERTIFICATE FOR *.POWERARCHIVER.COM HAS EXPIRED.

[noobian]

The first involves the 7Z format. To recreate the problem, do the following:

1)Create a small test file on your desktop named test.txt containing only the word “test”.

2. Right-click on the file, select PowerArchiver 2006 from the context menu and select “Compress with Options…”

3. Choose the 7Z radio button

4. click on the “Password…” button at the bottom right of the popup and enter the password “vanilla”, then re-enter the password.

5. Click on the Add button.

At this point, you should have two new files on your desktop, one named test.txt containing only the word “test”, and one named “test.7z”

6. Right-click on “test.7z”, select “PowerArchiver 2006” from the context menu and select “Extract Here”.

7. Enter an INCORRECT password in the password dialog popup and click OK.

8. You will get a popup “Confirm File Overwrite?”.

BEGS THE QUESTION: Why is PA asking permission to overwrite the file after the password has been entered incorrectly?<<<

Click on Yes (which shouldn’t be an option after the password has been entered incorrectly).

9. Open the file “test.txt” on the desktop and you will see that it is now corrupted!

If, at step 7 above, instead of entering an incorrect password, you entered nothing at all in the password window and just clicked OK, you still get the “Confirm Overwrite?” dialog, and if you click Yes, the file “test.txt” is corrupted. This also happens if you choose Cancel intead of OK in the password dialog.

At the point that the password is entered incorrectly whether blank or the wrong character sequence, PA should prompt for the correct password. When the cancel button is clicked in the password box, PA should stop the operation, changing NOTHING. In neither case should PA proceed to the “Confirm Overwrite?” popup if the password is not entered correctly.

The second bug relates the the BH file handling. The steps to reproduce are:

Repeat the steps above from 1 through 5 but instead of selecting the 7Z radio button, select the BH radio button.

You should now have two new files on your desktop, “test.txt” containing only the word “test”, and test.bh

Now, right click on test.bh, select “PowerArchiver 2006” and then “Extract Here” from the context menu.

You will get a “Confirm File Overwrite?” popup. Click Yes. Enter the password “vanilla” in the password field and click OK.

You will now see a popup stating:
"There is a CRC error on file: test.txt
Volume: test.bh

Continue?"

For both possible answers to the popup - whether at this point you click Yes to continue or No to not continue - then open the file test.txt, you’ll see that the file has been overwritten and corrupted.

Both of these BUGS can lead to critical data loss.

It took me all of 15 minutes after installing PA to find these two problems. Doesn’t inspire confidence.

[guido]

The first one is a known. But this is not a error. This is just the way it works. You loose nothing, the file is still inside the archive.

Don’t know about the second one.

Guido

[mwb1100]

@guido:

But this is not a error. This is just the way it works. You loose nothing, the file is still inside the archive.

I disagree - strongly - if you cannot enter the correct password when extracting, PA should not overwrite, modify, or corrupt any exisitng files. How can file corruption ever be considered ‘not a bug’?

Even if you can still get to the file inside the archive, I would consider this a serious error. But think about what’s happening here - the user might have forgotten the password (he’s not getting it right, remember), so trashing the uncompressed, unencrypted version of the file (even if it might not match what’s inside the archive) is a very bad error.

[spwolf]

@mwb1100:

I disagree - strongly - if you cannot enter the correct password when extracting, PA should not overwrite, modify, or corrupt any exisitng files. How can file corruption ever be considered ‘not a bug’?

Even if you can still get to the file inside the archive, I would consider this a serious error. But think about what’s happening here - the user might have forgotten the password (he’s not getting it right, remember), so trashing the uncompressed, unencrypted version of the file (even if it might not match what’s inside the archive) is a very bad error.

yes, it should not happen.

Problem is that 7zip engine by default does not use temp folder, so data is extracted over existing file. Until it is extracted, it does not know if password is correct or not. Keep in mind that PA does show you different file sizes in overwrite dialogue, although most people probably click away before reading anything.

Same problem happens with 7zip application and other applications supporting the format.

I hope we can be creative about this one for the future version.

As to the BH, thats an bug and will be fixed in future releases.

thanks for reporting…

[noobian]

@spwolf:

yes, it should not happen.

Problem is that 7zip engine by default does not use temp folder, so data is extracted over existing file. Until it is extracted, it does not know if password is correct or not. Keep in mind that PA does show you different file sizes in overwrite dialogue, although most people probably click away before reading anything.

Same problem happens with 7zip application and other applications supporting the format.

I hope we can be creative about this one for the future version.

As to the BH, thats an bug and will be fixed in future releases.

thanks for reporting…

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.

[spwolf]

@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 :-).