7-Zip 16.04 was released.
7-Zip for 32-bit Windows:
7-Zip for 64-bit Windows x64:
What's new after 7-Zip 16.03:
Please add MD5 file check in context menu
maybe a new feature in the installerthat offers to close and restart Explorer(or what ever is using 7z) so the update/install does not require a system restart
Better yet, if the Explorer shell extension code hasn't changed, don't update it. That way the reboot issue become moot. WinSCP does it this way and has not required a reboot for years.
OK. I'll think about dll version check for next version of exe installer.
Note also that default "reboot" button is "NO". And it's OK to press NO, if only dll is locked.
Isn't it easy to simply do a kill of explorer and runt it again? I do that often, manually, via Task Manager when a situation like this occurs. If a call can be made to kill and restart explorer, then that would be better and, of course, no rebooting.
I've done that to in the past... on the other hand using Process Explorer by Sys Internals I can kill the specific handle to that dll without having to kill Explorer as a whole.
In Vista+, doing that may cause issues with user privileges that Explorer will inherit after restart. If you restart it from a process running with administrative privileges it will inherit the privileges, and then problems arise.
From my personal experience installing 7-zip (x64) on Win 7 x64 over the past few years, I found that only when I reboot immediately after upgrading 7-zip would the latest version number & install-date be reflected correctly at Control Panel > Uninstall or Change a Program, as well as in 3rd-party uninstallers & apps like CCleaner.
Control Panel > Uninstall or Change a Program
Using the convenient method of kill-&-restart Explorer.exe (or logout-login) after every 7-zip upgrade, Control Panel & 3rd-party apps will fail to display the latest install-date. Instead, the date there shows the last time the system was rebooted immediately after upgrading 7-zip. However, the displayed version number does get updated to the latest, so the conflicting info can be quite confusing.
For instance, my Control Panel inaccurately shows that I installed 7-zip v16.04 (released: 04 Oct 2016) back in May 2016. That date refers to the time when I upgraded 7-zip to v16.02 (released: end May 2016) & rebooted immediately (or almost) w/o any interim system hibernation. I'd been consistently upgrading 7-zip to every new version released since then, but had always used the kill-&-restart Explorer.exe (or logout-login) method. Apparently, subsequent system reboots do not refresh the install-date.
As for clicking 'No' to system reboot, it seems that both the version number & install-date remain unchanged at Control Panel & 3rd-party apps. So if user tends to keep hibernating the system over several sessions rather than reboot, it gives the double-false impression that the installed 7-zip is outdated.
I upgraded/updated from v16.02 to v16.04 on a Win7 64bit.
Control Panel\All Control Panel Items\Programs and Features now shows I have 2 versions installed, see picture
Would expect the installer updates in stead of adding the new version under 'Programs and Features'
Note thate I have after the update only 1 '7-zip' folder under 'c:\program files'
There are 2 types of installer for 7-zip:
Exe installer now can't remove some things of msi version.
So if you don't like these 2 lines, you can remove msi version and install exe version again.
possible is change character encoding in ZIP archives to UTF-8 (-mcu=on) as default?
I receive archive created on Windows (with non-ANSI characters in the filenames) and I must decompress with p7zip on linux.
What about Windows users?
Can they unpack such archives with built-in zip unpacker in windows?
Please write your messages whithout screenshouts.
If we use -mcu switch, then at least some versions of Windows can't unpack such zip file correctly via built-in zip unpacker.
So it's not good ide to use -mcu by default.
With -mcu switch is not correct filenames in unpacker on Windows 7.
If I create zip archive with WinRAR, then is corretly on Windows unpacker and p7zip on Linux.
Rar uses another scheme:
DOS in main header + UTF8 in extra
7-Zip uses another scheme:
DOS or UTF8 in main header.
Maybe rar's scheme is better. But I'm not sure that I want to change it now.
Running the v16.04 . msi I receive the following error;
Error writing to file: C:\Program Files\7-Zip\Lang\en.ttt. Verify that you have access to that directory.
I can choose Cancel/Retry/Ignore, though if I choose Ignore, I receive the same error with the next language file and can only Cancel/Retry. Choosing Cancel at this point aborts the installation.
Try to remove folder "C:\Program Files\7-Zip\" and then install again.
Игорь, а нельзя сделать, чтобы опция - qs по умолчанию была включена (то есть применялся метод сортировки как и раньше), а новый метод уже нужно было бы включать. Просто самый популярный вопрос на форуме Ru-Board в профильной теме, это почему изменилась степень сжатия, получается во многих случаях без опции -qs она хуже. И люди не понимают совсем чем это может быть обусловленно.
"qs" is bad, if you extract archive to hdd - you will get wrong file order.
So you can get smaller archive (only in some cases), but slower work, if you do some operations with extracted files at HDD.
Smaller archive is good only at one time, but working files with wrong order can be problem after each system reboot (after each file cache clear).
It's problem for HDD where you have slow seek operation (10-20 ms).
SSD probably can work with any file order at same speed.
If you want all files sorted by name, then you must disable all filters (BCJ, Delta...).
Some files are extracted at the end.
Yes, it's so.
But the gain from filtered files is good in 99% cases. And the order is changed only for part of files. it's tradeoff.
Simplest case for thinking about order of files.
You unpack big .7z archive of source code (for example, 50000 files) to some folder in HDD.
Then after reboot you try to find something in these files with search command. HDD seek operation for files in wrong order will be very slow, maybe several times slower than "sequential-reading" search for case with "correct" order. And archive with "correct" order probably will be even slightly smaller.
Игорь, здравствуйте! Проблема! Обновил 7-zip с версии 16.02 до 16.04, установщик x64 msi. Архиватор после этого не запускается! Ни в какую. Explorer перезапускал. Система Windows 10 Enterprise 1607 x64.
1) try uninstall / reboot / install / reboot.
2) try to run 7zFM.exe from Explorer.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.