You can get @filename as name of archive or name of file in archive.
So I've disabled @ parsing after -- in 17.00.
But commands for FAR still use it after --.
It's my error.
the problem is more complicated.
I'll think about best way to fix it.
Last edit: Igor Pavlov 2017-06-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Version 17.00 exhibits a nasty bug compared to 16.04: When I try to create an archive of a folder containing "system volume information" with its default privileges, 16.04 simply reports a warning and skips this folder. Version 17.00 sometimes works and sometimes crashes, and the crash seems to vary somewhat - I have seen a simple "Unknown error", but also an exception 0xc0000005 at offset 0x0000000000036d71 (64-bit 7-zip 17.00).
Test scenario:
1) Create a small NTFS-formatted drive with the standard System Volume Information folder.
2) Go to its root.
3) Compress the drive normally: 7z a -mx0 -ptest c:\temp\test
4) Compress the drive differentially: 7z a -mx0 -ptest -u- -up0q3r2x2y2z0w2!"c:\temp\test-diff" c:\temp\test
Step 4 always works OK with 16.04 and sometimes fails with 17.00. I wasn't able to pinpoint the actual cause - it crashed for me when I was preparing the test scenario, but after I've typed it here I tried to execute it once more to be certain and I didn't get any crash :-(.
At least, going through my logs, the offset of the exception is always 0x0000000000036d71. Don't know if it helps any.
Pepak
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
pre-allocating file size is a great feature, Microsoft SQL Server does this on backups. As it is writing blocks to the end of the backup file, there is no need to write the new file size at the front of the file until the end. This has a noticeable impact on larger files (relative to disk size) for storage on HDD.
I like to right click on a folder, 7-Zip -> Add to "folder.7z". For a large file, it would be more efficient for 7z to be reading from the file, writing to a different disk (assuming a system with multiple hard drives).
I can do this with right click, 7-Zip -> Add to archive, but it would be nice to pre-configure a dedicated archive location,
thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a ~6GB zip file most likely created on a Mac that's giving me some troubles. The file wouldn't extract in 16.04, neither in 7z.exe or 7zg.exe. With 17.00, it still doesn't extract in 7zg.exe (the GUI is apparently stuck at 0%, the drive keeps on reading, but CPU usage of 7zg.exe isn't high) but it extracts correctly with "7z.exe x file.zip". ("Correctly" here is relative. This is an image of a VM, and all I know is that the image works after it's extracted. But I have no way of comparing file checksums with the originals.) All files inside the zip are <2GB and the zip is being read and extracted on an USB2 drive (not sure if this changes how Windows handles sparse files...)
Also, in the command line I get some warnings:
G:\bigstuff>"c:\Program Files\7-Zip\7z.exe" x zr_development_vm_urop_001.zip
7-Zip 17.00 beta (x64) : Copyright (c) 1999-2017 Igor Pavlov : 2017-04-29
Scanning the drive for archives:
1 file, 6012822829 bytes (5735 MiB)
Extracting archive: zr_development_vm_urop_001.zip
WARNINGS:
32-bit overflow in headers
--
Path = zr_development_vm_urop_001.zip
Type = zip
WARNING = 32-bit overflow in headers
Physical Size = 6012822829
Characteristics = Local Central
Everything is Ok
Archives with Warnings: 1
Warnings: 1
Folders: 19
Files: 609
Size: 12258696989
Compressed: 6012822829
I can provide the zip file to you privately if you're interested.
Danilo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem with big zips from mac was fixed in 7-zip 17.00 beta.
So both 7z.exe and 7zg.exe must work.
Check it again.
If 7zg.exe doesn't work still, probably you have some old version of 7-zip (32-bit or 64-bit) in some folder and you used it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After viewing or editing password-protected files (without prior extraction) and subsequent closure of the file and the program "7ZIP", copies of PW protected files is not deleted from the local temporary folder for the Windows 7 64 bit users, and remains there in the clear indefinitely. This occurs as in version 16.04, so in the latest 17.00. At the same time, 9.20 version of the program always removes the temporary file when you close the viewed file.
Forced return to 9.20 :(
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I just tried the 17.00b from the web site and i have some issues...
On my NAS i have a larger rar file (approx: 70GB into 2 parts (50GB/20GB), with 20 files of 3.5GB), my NAS have approx 85GB of free space.
When i tried to unrar the file from my computer to the NAS (right click, extract here), the process work until i have a "network error" (the NAS seems freezing, my network directory has been completly unvailable for approx 5sec).
On my NAS, 52GB left after this first try and a couple of files are missing... so...
I tried to unrar it again without overwriting the existing files but again i had the "network error" status (NAS has been again unvailable for a couple of seconds... it's as if the samba server on the NAS side was completly out of control...).
--> Some Pre-allocated files seems to have been created but wihtout any real data into them... (so how can you really know which files can be overwrited ??? without a pre-allocated file, the data size could be checked... in that case it can't be... (because pre-allocated file and final file have the exact same size...), my NAS work in ext4 so fragmentation is unconsistent in my case... Could you make it has an option please ? i clearly have a preference for the "on the fly" method^^).
I am back to the 16.04 stable release, and tried to extract only the missing files... no issue with that release.
I hope, pre-allocated file will be an option, uncheck by default like BT clients or other software ^^
Thanks for all your work ^^ I hope you will find the "network error" cause.
Last edit: Thibault Capdevielle 2017-08-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
pre-allocated file probably will have "current_time" timestamp.
Correct file must have "modified_time" timestamp.
So you can see it with "modified" column sorting, or in "overwrite" window.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
Igor Pavlov
How are you looking at making changes to the code that your modifier introduced in your sources as an "Easy 7-Zip" program - http://www.e7z.org?
Igor,
Whether the subsequent versions is not possible to take into account the changes that brought on his own creator "Easy 7-Zip"?
With the changes in the following range can be read at:http://www.e7z.org/ Adds icons to context menu Adds options to Extract dialog Keeps same output folder history Minimizes to system tray when clicking "Background" on progress dialog thank you in advance for the inclination for changes new installation file
Thank you in advance for the inclination for changes
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In 17.00 beta command
7z x -r0 -y -scsDOS -- Z:\7z1700-extra.7z @Z:\FAR00008.2K1
is extracting nothing. Last working version was 16.04.
7-Zip [64] 16.04 : Copyright (c) 1999-2016 Igor Pavlov : 2016-10-04
7-Zip 17.00 beta (x64) : Copyright (c) 1999-2017 Igor Pavlov : 2017-04-29
List file (Z:\FAR00008.2K1) content:
Last edit: Vidmantas Balciunas 2017-06-07
You can get @filename as name of archive or name of file in archive.
So I've disabled @ parsing after -- in 17.00.
But commands for FAR still use it after --.
It's my error.
the problem is more complicated.
I'll think about best way to fix it.
Last edit: Igor Pavlov 2017-06-07
Not fixed in new version. Why?
You can use -i@listfile.txt switch before -- switch. It works with any version of 7-zip.
Rarlab fixed a security bug in their extractor. Is 7z affected by this bug?
I suppose that problem in 7-zip's code is not so critical as in original rar code.
It will be fixed in next version of 7-zip.
Version 17.00 exhibits a nasty bug compared to 16.04: When I try to create an archive of a folder containing "system volume information" with its default privileges, 16.04 simply reports a warning and skips this folder. Version 17.00 sometimes works and sometimes crashes, and the crash seems to vary somewhat - I have seen a simple "Unknown error", but also an exception 0xc0000005 at offset 0x0000000000036d71 (64-bit 7-zip 17.00).
Test scenario:
1) Create a small NTFS-formatted drive with the standard System Volume Information folder.
2) Go to its root.
3) Compress the drive normally: 7z a -mx0 -ptest c:\temp\test
4) Compress the drive differentially: 7z a -mx0 -ptest -u- -up0q3r2x2y2z0w2!"c:\temp\test-diff" c:\temp\test
Step 4 always works OK with 16.04 and sometimes fails with 17.00. I wasn't able to pinpoint the actual cause - it crashed for me when I was preparing the test scenario, but after I've typed it here I tried to execute it once more to be certain and I didn't get any crash :-(.
At least, going through my logs, the offset of the exception is always 0x0000000000036d71. Don't know if it helps any.
Pepak
Yes, 17.00 crashes for commands that write anti-item to 7z archive.
it will be fixed in 17.01.
pre-allocating file size is a great feature, Microsoft SQL Server does this on backups. As it is writing blocks to the end of the backup file, there is no need to write the new file size at the front of the file until the end. This has a noticeable impact on larger files (relative to disk size) for storage on HDD.
I like to right click on a folder, 7-Zip -> Add to "folder.7z". For a large file, it would be more efficient for 7z to be reading from the file, writing to a different disk (assuming a system with multiple hard drives).
I can do this with right click, 7-Zip -> Add to archive, but it would be nice to pre-configure a dedicated archive location,
thanks
Hi Igor,
I have a ~6GB zip file most likely created on a Mac that's giving me some troubles. The file wouldn't extract in 16.04, neither in 7z.exe or 7zg.exe. With 17.00, it still doesn't extract in 7zg.exe (the GUI is apparently stuck at 0%, the drive keeps on reading, but CPU usage of 7zg.exe isn't high) but it extracts correctly with "7z.exe x file.zip". ("Correctly" here is relative. This is an image of a VM, and all I know is that the image works after it's extracted. But I have no way of comparing file checksums with the originals.) All files inside the zip are <2GB and the zip is being read and extracted on an USB2 drive (not sure if this changes how Windows handles sparse files...)
Also, in the command line I get some warnings:
I can provide the zip file to you privately if you're interested.
Danilo
The problem with big zips from mac was fixed in 7-zip 17.00 beta.
So both 7z.exe and 7zg.exe must work.
Check it again.
If 7zg.exe doesn't work still, probably you have some old version of 7-zip (32-bit or 64-bit) in some folder and you used it.
Is bug 2059 (explorer not restarting during uninstall / upgrade) fixed in 17.00?
https://sourceforge.net/p/sevenzip/bugs/2059/
This would be a big move to help getting enterprises to upgrade!
After viewing or editing password-protected files (without prior extraction) and subsequent closure of the file and the program "7ZIP", copies of PW protected files is not deleted from the local temporary folder for the Windows 7 64 bit users, and remains there in the clear indefinitely. This occurs as in version 16.04, so in the latest 17.00. At the same time, 9.20 version of the program always removes the temporary file when you close the viewed file.
Forced return to 9.20 :(
What is the targeted release date for v17.0
Hello,
I just tried the 17.00b from the web site and i have some issues...
--> Some Pre-allocated files seems to have been created but wihtout any real data into them... (so how can you really know which files can be overwrited ??? without a pre-allocated file, the data size could be checked... in that case it can't be... (because pre-allocated file and final file have the exact same size...), my NAS work in ext4 so fragmentation is unconsistent in my case... Could you make it has an option please ? i clearly have a preference for the "on the fly" method^^).
I am back to the 16.04 stable release, and tried to extract only the missing files... no issue with that release.
I hope, pre-allocated file will be an option, uncheck by default like BT clients or other software ^^
Thanks for all your work ^^ I hope you will find the "network error" cause.
Last edit: Thibault Capdevielle 2017-08-14
pre-allocated file probably will have "current_time" timestamp.
Correct file must have "modified_time" timestamp.
So you can see it with "modified" column sorting, or in "overwrite" window.
Hello,
Igor Pavlov
How are you looking at making changes to the code that your modifier introduced in your sources as an "Easy 7-Zip" program - http://www.e7z.org?
7-Zip icons replacement -based on files from 7-Zip Theme Manager or added support for the ability to use skins/themes - http://www.7ztm.de/index.php?cat=01_Engli7-Zip Theme Manager or added
https://sourceforge.net/p/sevenzip/discussion/45797/thread/32cf3313/
Igor,
Whether the subsequent versions is not possible to take into account the changes that brought on his own creator "Easy 7-Zip"?
With the changes in the following range can be read at:http://www.e7z.org/
Adds icons to context menu
Adds options to Extract dialog
Keeps same output folder history
Minimizes to system tray when clicking "Background" on progress dialog
thank you in advance for the inclination for changes
new installation file
Thank you in advance for the inclination for changes
What is the release date for v17.0
You can find it in the first post :-)
2017-04-29