Umar Umar

I've had Defender flag legit tools with that same Wacatac.C!ml label before, so I wouldn't panic yet. I downloaded my copy fresh from the official 7-Zip site and checked the file hash against the one listed there, and when it matched I restored it from quarantine and added an exclusion for it.

Yes, that is possible if you make the archive again in the 7z format and tick Encrypt file names in the Add to Archive window, along with setting a password and AES-256. Then 7-Zip asks for the password as soon as you try to open the archive, instead of only when you open a file inside it. I do it that way for folders I share, but you cannot add that password to an archive you already made, so you will need to create a fresh one with the files in it.

You are not doing anything wrong. That .crdownload file just means Chrome had not finished the download yet, so the 7-Zip installer was still incomplete. I have had the same thing happen on a slow connection, and deleting the .crdownload file and downloading again from the 7-Zip site fixed it for me.

You are not doing anything wrong. 7z treats * and ? as wildcards in its own arguments, so ./test/ is read as a pattern rather than a literal folder name, which is why the base folder ends up in the archive for those two and not for 'te st'. The shell escaping only stops bash from expanding it; 7z then does its own wildcard matching. The workaround I use is renaming the folder to drop the * or ? before archiving, since I have not found a way to escape a literal wildcard in 7z's command line.

That -mmc=10000000 is the culprit, I made the same mistake on a folder of scanned PDFs once. It tells the matcher to search far more combinations than normal, and on a PDF there is almost nothing left to squeeze since the file is already compressed inside. I dropped the -mmc override and used -mx3 instead, and the same batch finished in minutes with an archive only a little bigger.

Thanks for the update, Igor. I mostly use 7-Zip for everyday archiving on Windows, and I appreciate that each release stays light and doesn't pile on extras. The Linux split-file fix is a nice touch for the times I get archives from friends on Linux.

I hit this same error compressing a big folder at Ultra with a large dictionary, and dropping the dictionary size down fixed it for me too. The memory shown in the dialog is only an estimate, so on a 16 GB machine a 256 MB dictionary with a 4 GB solid block can still run out. I also delete the old archive before starting a fresh one now, since updating in place uses more memory.

I ran into the same thing on Windows, and in my experience 7-Zip just recreates the symlink when it extracts it, so you get the link and not the file it points to. I have not found a switch that makes it follow the link inside the archive. What worked for me was extracting the target file itself by name instead of the symlink, which gave me the real contents straight away.