7zip Not Working

[Arridano Tillo]

Whenever I extract an archive using 7-Zip, it performs a two step operation. First it extracts the contents of the archives to a temporary folder, then Windows copies the files from the temporary folder to the target directory.

The second part of this operation can take some time, especially if there were a large number of small files in the archive. It seems like the operation could be sped up if 7-Zip just extracted the files directly to the target directory to start with. Is there a way to make it do this?

7-Zip doesn't know folder path of drop target. Only Windows Explorer knows exact drop target. And Windows Explorer needs files (drag source) as decompressed files on disk. So 7-Zip extracts files from archive to temp folder and then 7-Zip notifies Windows Explorer about paths of these temp files. Then Windows Explorer copies these files to drop target folder.

You can press F9 inside 7-Zip, you'll get two panes. In the first you navigate to the archive you want to extract, and in the second you navigate to the folder where you want your files extracted. This will skip the temp folder step.

I can confirm each "solution" here (having tested with 32 and 64 bit variants) and I would like to add something:Drag and Drop is ALWAYS a two step solution when moving between applications, there's just no way around that even with apps inside the same development ecosystem like Microsoft or Adobe titles. The reason won't surprise you.Different applications don't talk to each other directly when moving files between them by drag and drop. This functionality is handled by the OS, no matter which OS you are using. On Windows, FileExplorer will take over from App-A (which is sending), and get a link to the file it is using--if a file does not exist yet, you will get the chance to save a file in some apps, others create a temporary file in a space you specify or use the system temp cache--; this link will then be used by App-B (which is receiving).A compressed archive is only a collection of bits that need to be unscrambled and decompressed into the file(s) the archive contains. When you drag and drop from the 7zip to a FileExplorer window, those files must first be decompressed to a temporary location as they don't yet exist, then they can be moved. This is because 7zip DOES NOT EXTEND the FileExplorer, it is a separate application. However, drag and drop between 2 windows of 7zip will not require this temporary space, it can do it all directly in memory. The same function is found by using the EXTRACT function and giving it a path to dump the files into. However, you should not MOVE or COPY if you wish to avoid temp-caching. Again, these create a temporary working copy, then move that to the path you give them.You can still select single or multiple items of varying type and size, then Extract them, or drag-and-drop into another 7zip window.

If the end-user sends a password protected compressed folder to me for troubleshooting I am unable to open it via Windows compression, however if I open the password protected file using 7zip it does work.

I also had tried using the .zip file extension as well as using Zipcrypto instead of the AES encryption. Even after using those recommendations it does not work. Currently we are using a work around for the user to go to a different PC to use this same process to create the zipped password files.

I have found 4 different cases of this since March 15th. Not sure, but guessing it might have something to due with the March Windows update. I have both Windows 10 and 11 having the issue. Had to revert to 7zip. Also, should mention, many other computers have installed the same updates and not having the issue.

Also, I have the issue with computers running SentinelOne EDR. Are any of you using SentinelOne or something different. I am wondering if one of the Windows updates is conflicting with SentinelOne somehow. SentinelOne is not alerting to anything related to the zip files.

Although I choose Tools->Options->Folders->Working folder and specify a particular hard-drive folder, 7-zip seems to use my user TEMP folder when unpacking. Is this intended? I assumed that choosing the working folder above would prevent TEMP being used.

(My TEMP folder is on a ram-drive which is not always big enough for large archive unpacking - and when I get the error message, not enough disk space, the process hangs and I have to kill it using Task Manager).

It is not a bug. The working folder you specify in settings is used for archive update operations, so it is equivalent to the -w command-line switch. For drag-and-drop operations, 7-Zip does not know the target folder, but it still has to write files somewhere. There is not so many standard writeable folders, among which only TEMP is present in each system. TEMP is also used when you view files from archives.

But why hard code the drag target directory as TEMP? You can simply use the Options->Folders directory, which defaults to TEMP anyway. You already have to check for the optional directory actual existance when using it for other operations. Seems trivial to me. When people are creating wrapper scripts, dragging multi-gig files that are doubly stored, filling up ram disks, having dragged out files end up encrypted because TEMP is encrypted (my case), then something is wrong here. What am I missing? If it's something technical I can be educated. BTW, I love 7-Zip. Thank you for your hard work on your great tool.

I've the same issue as the Op, despite specifying a Working Directory location it is ignored for some operations despite the program knowing a custom path is specified and stored in its configuration data...

I made a backup tool for MS SQL Express that -daily- backs up, 7zips and uploads the zipped files via FTP.It is a program made in VB.net, built as an .EXE with a .config file. One of the functions calls a file "7zip.exe".Anyway, on Win2003 (20 webservers) this works perfect. Small databases, big databases, slow servers, powerstations... The 'daily basis' is created by launching a scheduled task at night.

Now in Win2008 R1 I also created a 'basic task' and set it up.When I launch it, I see it working except the 7 zip does nothing. It has something to do with the scheduled task because when I run the .EXE normally (double clicking...) it 7zips, as it should be.

Windows Server 2008 made some changes to Scheduled Tasks, but I don't remember the specifics. I do remember having to update some tasks when I went from 2003 to 2008. You might need to assign a user to the task, even if it's a local job. If a regular user doesn't work, try a local admin user.

Thanks resolove my issue. becuase on windows server 2008 need full path while raring:On my scenario i schediled a batch script to zip one file everyday,but it didnt work as below my old script:"C:\Program Files\WinRAR\WinRAR.exe" a test.rar test.txt : this didnt work

I'm in an interesting predicament. I have an encrypted 7z file that I made myself. The password for the file is a 60 character generated password that I saved to my password manager. I made sure to test the password before putting anything in the encrypted file, to make sure I could reopen it. It's now a few months later and I'm trying to open the encrypted file and the password isn't working. ("Cannot open encrypted archive F:\secretstuff.7z. Wrong password?")

I know brute forcing a 60 character password would takes years, but since I have the expected password is there some software out there that takes the password and makes mutations of it until it can create a password that matches the file hash? I'm suspecting that I accidentally added a character somewhere when setting up the encrypted file, that didn't make it into the password manager or the 7zip GUI has a max password character limit for creating encrypted files that I hit without knowing it.

I have tried looking around but all I could find software's that use a dictionary attacks or brute force to crack the password. Both are useless because dictionary would only work if it is an easy to guess password, but mines is randomly generated and the brute force method would likely succeed long after I had died of old age (assuming the password is a mutation of the original password). I have used John the ripper to extract the file hash, but I have no idea what to do now. Any ideas or solutions that you think I should try would be greatly appreciated.

The first thing you should try is checking whether you accidently added a character to your password. To check that we create a dictionary based on the presumable password but with an increasing amount of chars iteratively removed.

Then we will do the same with 2 chars at a time again and so on, theoretically until we have all chars of the password except 1 replaced with ?a, since this is extremely performance intensive, we will crop the replacement at 10 chars maximum.

I just created a 7-zip archive here with an older tool, added password, and wrote out the 7z file to my Desktop. I right-clicked on this file, chose Open with, and using TheUnarchiver, was able to supply the password and extract the content correctly. On OS X El Capitan 10.11.6.

The error message implies it is using a (presumed) newer variant of .7z than the Mac tools you have tried support. I encountered a similar issue with a .rar file recently which was in the new version 5 RAR format.

Whilst there are at least two tools that I know now support v5 of RAR on a Mac I do not what format/version your file is in and whether any Mac tools support it. You can see information about the .7z format here -zip.org/7z.html

The same website lists various .7z tools that either they provide or recommend. The only Mac tool listed for .7z files is Keka which is what I have myself used in the past. The current version of Keka is 1.0.9 but there is a Keka 1.1.0beta which you could also try. See

Most compression tools and formats actually have multiple different compression schemes they can use although most of the time these choices are hidden and unnecessary. Zip has multiple variants, RAR has and so does .7z, if you look at the first webpage I linked to i.e. the .7z website you can see it lists at least seven different versions it can do. When you created a new test file and then successfully opened it you will have created it using a variant your tool understood, the problem here seems to be it has been created with a more esoteric or newer variant than the Mac tools you have tried understand.

c80f0f1006