I noticed a weird password-related quirk with the latest release of 7-zip (v9.20). Is 7-zip supposed to behave this way?
The following are the steps I did that you also can try in order to illustrate this particular issue:
1. Create a new text file named "example.txt" with text "Merry Christmas!" and save it
2. Right-click the "example.txt" file to get 7-zip's context menu
3. Choose "Add to archive…" and archive "example.txt" as "last.7z" with password "Pavlov"
4. Right-click the "last.7z" file to get 7-zip's context menu
5. Choose "Add to archive…" and archive "last.7z" as "first.7z" with password "Igor"
6. Delete files "last.7z" and "example.txt" from the folder, leaving only "first.7z"
7. Double-click "first.7z" and when 7-zip opens it, type the first password, "Igor"
8. Double-click on "last.7z" in the 7-zip window and enter the second password, "Pavlov"
9. Double-click on the (two-password protected) "example.txt" file to confirm its contents
10. If desired, close the 3 windows and repeat steps 7-9 to confirm they still work the same way
11. Now add to the "example.txt" file the additional words "And Happy New Year!"
12. Close the text file, telling it to save the changes
13. Confirm also that you want 7-zip to update the modified file in the archive
14. Close that 7-zip window and again confirm that you want to update THAT archive as well
15. Try to repeat steps 7-9 and note that the first password "Igor" NO LONGER WORKS
16. Try using "Pavlov" as BOTH the first and second passwords
17. The two passwords on the internal "example.txt" are now THE SAME. Is 7-zip supposed to do this?
If you try this technique with THREE ("nested") archives/passwords instead of two archives/passwords…
…the following happens after the FIRST "example.txt" change:
The 1st password becomes the 2nd, the 2nd becomes the 3rd, and the 3rd stays the same
…and the following happens after the SECOND (and subsequent) "example.txt" change(s):
The 1st password becomes the 3rd, the 2nd remains as the 3rd, and the 3rd stays the same (all become the same)
The contents of the example text file may also then corrupt. (Yikes!)
(I had never tested this before, but I also now notice that 7-zip version 4.65 ALSO corrupted the example text file.)
(I'm also not sure if typing the "wrong" password (instead of the "expected changed" password) alters the "change" process.)
Try it with FOUR instead of THREE, and after three (or more) changes to "example.txt",
the "innermost" password "works it way outward" and replaces the other passwords.
Is this a bug that could be fixed in a future release?
The archive password changing in itself isn't the worst thing, but the file corruption is.
Thank you for your kind attention, and Merry Christmas! :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I noticed a weird password-related quirk with the latest release of 7-zip (v9.20). Is 7-zip supposed to behave this way?
The following are the steps I did that you also can try in order to illustrate this particular issue:
1. Create a new text file named "example.txt" with text "Merry Christmas!" and save it
2. Right-click the "example.txt" file to get 7-zip's context menu
3. Choose "Add to archive…" and archive "example.txt" as "last.7z" with password "Pavlov"
4. Right-click the "last.7z" file to get 7-zip's context menu
5. Choose "Add to archive…" and archive "last.7z" as "first.7z" with password "Igor"
6. Delete files "last.7z" and "example.txt" from the folder, leaving only "first.7z"
7. Double-click "first.7z" and when 7-zip opens it, type the first password, "Igor"
8. Double-click on "last.7z" in the 7-zip window and enter the second password, "Pavlov"
9. Double-click on the (two-password protected) "example.txt" file to confirm its contents
10. If desired, close the 3 windows and repeat steps 7-9 to confirm they still work the same way
11. Now add to the "example.txt" file the additional words "And Happy New Year!"
12. Close the text file, telling it to save the changes
13. Confirm also that you want 7-zip to update the modified file in the archive
14. Close that 7-zip window and again confirm that you want to update THAT archive as well
15. Try to repeat steps 7-9 and note that the first password "Igor" NO LONGER WORKS
16. Try using "Pavlov" as BOTH the first and second passwords
17. The two passwords on the internal "example.txt" are now THE SAME. Is 7-zip supposed to do this?
If you try this technique with THREE ("nested") archives/passwords instead of two archives/passwords…
…the following happens after the FIRST "example.txt" change:
The 1st password becomes the 2nd, the 2nd becomes the 3rd, and the 3rd stays the same
…and the following happens after the SECOND (and subsequent) "example.txt" change(s):
The 1st password becomes the 3rd, the 2nd remains as the 3rd, and the 3rd stays the same (all become the same)
The contents of the example text file may also then corrupt. (Yikes!)
(I had never tested this before, but I also now notice that 7-zip version 4.65 ALSO corrupted the example text file.)
(I'm also not sure if typing the "wrong" password (instead of the "expected changed" password) alters the "change" process.)
Try it with FOUR instead of THREE, and after three (or more) changes to "example.txt",
the "innermost" password "works it way outward" and replaces the other passwords.
Is this a bug that could be fixed in a future release?
The archive password changing in itself isn't the worst thing, but the file corruption is.
Thank you for your kind attention, and Merry Christmas! :-)
Thanks for BUG repport!
Please check fixed version:
http://dl.7-zip.org/7z920.04.7z
Does this password related fault affect the CL version too? John
Does this password related fault affect the CL version too? John
It's File Manager problem only.