Updating Password Protected Archives

1. Create any password protected archive
2. Right-click the files or files in Windows Explorer and select "Add to archive" to update the archive

Result: The archive is no longer password protected.

IMO it would be much better if the archive would simply retain its original password on updating, or perhaps the user should be requested to enter the password on updating the archive.

What do others think about this?

thats not correct.

when i create an archive (7z) with password, and add files then 7-zip ask me about the password… after the process the archive is password protected…

successful with 7z ,zip

Of course it is correct. Have you tested it properly? .

Are you just using the right-click menu, or are you opening the dialogue?

Say: create Files.7z with a password from one or more files.
Then: select the files right-click, and add to Files.7z

Even if you do use the dialogue, it does not demand a password. The password field is blank, and just clicking OK without retyping the password will remove the password.

I want to use the right-click menu directly, but I want the password protection to be retained. Typically, I right-click  on a folder, or a single file, or a range of selected files, and the archive name is the current folder's name.

Hello everyone,

which OS do you use?
When I try to reproduce your problem using the context-menu 7-Zip asks for the password before adding the new file to the archive.
If I open the archive with 7-Zip and add a file by using  the archive is updated and the new file is not password-protected. But the first file stays password-protected.
My system is XP with SP3.

Best regards!

I am also using Windows XP Home SP3.

These are the two cases I use most frequently:

1. Archive single file with password — password is removed if I just right-click and update.
2. Archive single folder with password — password is removed

Hello everyone,

call me demanding, but please check again if the first (password-protected) file in the archive is still protected or not. You are true in a way -> the archive is not protected any more, but the files that were the origin of the archive are still protected.
If you want to update an existing (password-protected) archive you have to tell 7-Zip to protected the new files too by simply giving the same password again (as you did while creating the original archive).

Best regards!

I actually appreciate the quick feedback. I don't mind you being demanding. That's how bugs and issues get resolved. The problem often lies between the keyboard and the chair. In this case, I think the problem lies in the design of the software.

As you say, if you update a password protected archive previously protected files that were not changed are still protected, but new ones are not. In the case of my single file protected archive, then all of the files are no longer protected.

If possible, I wish to avoid being asked for the password again, but at least 7-Zip should ask for the password before adding another file to a protected archive. I'm not sure how useful it would be to have an archive with some files protected and some not protected, and one doesn't always want to use the dialogue. Its much quicker to right-click and update the archive.

Hello everyone,

I can only reproduce this behaviour if I open the archive in 7-Zip (which brings up the dialog to give in the password) and add a file by copying it with  from one panel into the the archive in the other panel. If I add a file via context-menu 7-Zip asks for the password and adds the new file encrypted to the archive. Not consistent, but that way it works for me (at least with the files I tested yet).
Igor…?

Best regards!

I guess i get what pesala means, when updating archive and EncryptFileNames  flag not set(in dialog), sevenzip not preserving this flag from archive, so content can be listed, but files are still password protected.

Hello everyone,
yep. That's why I wrote:

but the files that were the origin of the archive are still protected.

Interestingly I found 7-Zip acting correctly as expected when using the context-menu (at least for me). Anyone can confirm / reject that observation?

Best regards!

@pesala

yes i have test it.

os: win7x64
7-zip 9.20

all actions run without problems

archives always protected…

Then you did not test it properly, or this issue does not affect your OS or your 7-Zip version. I am using the latest version.

1. Right click on "filename.txt"
2. Add to archive
3. Type password

A password protected archive is created named "filename.7z" Attempting to open filename.txt from the archive shows a dialogue requesting a password.

4. Right-click on the same text file again
5. Add to "filename.7z"

The protection is removed from the archive without any warning.
Exactly the same thing happens when updating an archive created from a folder.

1. Right click on a folder named "Folder Name"
2. Add to archive
3. Type password

A password protected archive is created named "Folder Name.7z" Attempting to open any file from the archive shows a dialogue requesting a password.

4. Right-click on the same folder
5. Add to "Folder Name.7z"

The protection is removed from the archive without any warning. Any file in the archive can be extracted.

Hello everyone,

sorry, as I mentioned above:
following your steps (right-click a file -> context-menu -> … -> same file again by context-menu -> …) works for me as expected => the "give-in-password"-dialog pops up -> the archive is updated -> when opening the archive  => file is protected and 7-Zip asks for password before opening the archive!
But: Opening the archive in 7zFM.exe and updating the same file by  does what you describe. That's why I asked Igor for a comment.

Best regards!

pesala:
When you call "add to "Folder Name.7z", you tell 7-zip to add file/folder to "Folder Name.7z" archive.

That command is not
"add to Folder Name.7z and check what encryption was used for same files in that archive before and keep same encryption method".

So everything is OK there.

No, its not OK. The archive was protected, now its not.

Adding files to a protected archive should either ask for the password, or retain the existing password.

Hello everyone,

I double-checked again:
-> if you use context-menu it works as expected!
- if you do this inside 7-Zip's filemanager the first file stays protected if you add some other file
- if you do this in 7-Zip's filemanager and add the same file without password only the file without password is inside the archive
Conclusion => if you only want to update the file(s) that are already inside an archive, either use the context-menu or be sure to give in the password again
I have to admit, that it is not easy to understand why these two ways (GUI <-> context-menu) behave different.

Best regards!

I also think that this is not expected behaviour of 7zip's filemanager. As we often create a password-proteced archive in our company with files from several folders, the files that are added at first are password-proteced, then when later adding other files to the same archive using the GUI, no password is asked for and the newly added files are unprotected. I see this as a bug.
I did not know that using the Windows explorer context-menu behaves different (in my eyes correctly), but that is not a solution for us as the archive is in one folder and files from several other folders gets added, so you cannot achieve that task just with the context-menu.
As there was no solution I created a small front-end on my own for 7-Zip for just that task, you can add files to an existing archive with a password-box, where you have to enter the same password as before. It would be nicer to have that "feature" included in original 7-Zip, but as it is like that for so long, I did believe this was done on purpose…

Best regards!

Hello everyone,

would you mind to share your frontend?

Best regards!

The issue is not with the File Manager, but with the Windows Explorer right-click menu.

The behaviour is wrong. A protected file should not be unprotected after updating it.

Hello,

I know this is an old topic but I didn't want to open a new one for the same subject.
What happened with me is that I created an encrypted archive with the filenames also encrypted. all worked fine, until I added some files to the archive through the GUI, and suddenly the archive could be easily opened without a password and all filenames viewed. but when trying to open one of the files, it would still require a password at least.

I believe this is dangerous as no notification was given to me that the filenames would stop being encrypted, and new files will be added unencrypted.
Kindly advise if there is any intention to fix this behaviour, or should I look for another solution for encryption..

BTW, thanx for a great product..

I am having this problem as well.
1. I create archive with encrypted file names.
2. Password is required to open/view the archive.
3. I add a file to the archive(drag and drop).
4. Now, no password is required to open the archive and view the contents of the the archive. No password is needed to open the any files added post archive creation.

Please fix…

Hi, I am having the same problem, both with the 9.22 beta versions as well as with previous ones in both Windows XP (SP2 and SP3) and in Windows 7 Pro x64.

Opening a previously created, password-protected archive .7z whose file names are encrypted, and adding (by drag & drop) one or more files cancels such encryption of the file names. In addition, if the archive contains folders, then those folders can be opened and the file names are displayed. The password is still required to open or extract the old files, but all the newly added files can be opened without a password.

This security weakness is a major problem in a compression tool that otherwise leaves others behind. Please consider reviewing the code to track the error.  TIA.

Clearly other users agree with me that the current behaviour is wrong, and a security hazard.

If I enter my front door I need to use my door key to unlock the Yale lock.
When I leave the house I just close the door behind me — I don't need to lock it.

An archive that has previously been protected should not be unprotected after updating files in that archive.

March 2013 and still no go?
I've spent quite some time trying to add extra (new) files to an existing ZIP archive and have them encrypted.

The only way how to be able to type in the password is
x to pretend to create a new archive... via context menu,
x then to choose the path & name of the existing archive,
x finally not to forget to delete the existing archive file name's extension (otherwise a new archive will be created with name archive.zip.zip)

Easiest way would be to have an option in the 7-zip GUI to "Add" new files, which would prompt the user for compression & encryption details. It would be great if that "Add button" in GUI also supported simple drag&drop.

I'm having the same problem. I've just recently discovered 7-Zip and was going to start using it to keep my files secure. I've still been using winzip 8 until now and to get around major hacking problems I keep an encrypted archive inside another archive. The additional benefits of this were that you only password in one place and you can add an subtract files willy nilly inside the inner archive, they didn't need to be passworded.
So I'm testing 7-Zip, I open the first file, shell.zip, no problems. Inside is another file, data.zip which is encrypted. I open this, give the password and see my files. All is well so far. Now I modify one of those file, I add a line of text to text.txt. I save the file and go back. 7-Zip asks me if I want to update the file. I say yes. All is still well. Now I traverse back out to shell.zip and 7-Zip again says that data.zip has changed and asks if I want to update it. I say yes. HOWEVER, IT REMOVED THE PASSWORD. MY archive is NOW NOT PROTECTED.
To add to the injury, I CAN'T CLICK ANYWHERE AND PUT THE PASSWORD BACK. I have to do a major stuff around moving the archive to a temporary directory and then add it back where it was so that I can put a password in again.

Because of this flaw I am not going to use 7-Zip until it is fixed, I will keep using winzip 8 (which I had paid for and is still good provided I take precautions).

This problem also happens with .7z files, not just .zip. It's a major bug.

I have to agree with Brox above, without this bug 7-Zip left the others for dead. But with this bug winzip is still a better product.