7zip Not Implemented Error

[Jacinda Saleeby]

Whenchanging (removing) data from an existing ZIP file, one of my colleagues gets an error "Not implemented". We tried upgrading to the newest 7-ZIP version, but that also didn't resolve the issue...

Does anyone have a fix for this?

I have two guesses: either the ZIP is nonstandard/broken, or it uses some rare method (e.g. central directory is compressed). What are you trying to delete: a file or a folder? Could you post any ZIP file (if it isn't too big) that causes that error?

We have Cadmatic software that creates backup files as a .bup files. We often need to access these files and edit content and we are using 7 zip for it. Usually everything works just fine, but sometimes I get error "Not Implemented". It happens sometimes when editing some name of a file inside .bup file, or when trying to add or delete files inside .bup files. It happens for different files, but later it might work withour errors with same file that i had this error before, even when doing the exact same operation. I can ofcourse always work around this issue when it is occurring by unzipping .bup file to a regular folder, then edit the files and afterwards zipping it back to .bup file.

I updated 7 zip version to newest 18.01 (x64), but it did not fix the issue and I still get the same Not Implemented error from time to time, as I used to get with older 7 zip versions. I use 7 zip for editing the files on two Windows servers, other one is 2012 and other one is 2008 R2, and both of the servers has this occasional problem with 7 zip.

However I cannot see "Info" button when this error appears. I am trying to rename file restore.ini to restore1.ini just to make a point. First 5 .bup files I tried, I was able to rename the file, but with this file I receive "Not Implemented" error. My 7 zip is in Finnish, but it basically states "Error when trying to rename file or folder" "Not Implemented". Where I can check for possible header errors?

Hi, there are no "Header Error" lines either when modifying (in this example renaming a file inside .bup file) works or when it doesn't work. Here is one example of the content of "Info" when modifying did not work (see pic).

I'm using 7zip now for many years and always thought "well it's not implemented" until I saw this discussion. Anyway, for many years on all my computers I have this issue. Also the "add" button gives the error. I can't add, remove, or whatever files.

You must run 7-Zip File Manager in administrator mode. Right-click the icon of 7-Zip File Manager, and then click Run as administrator.Then you can change file associations and some other options.

You can get big difference in compression ratio for different sorting methods,if dictionary size is smaller than total size of files.If there are similar files in different folders, the sorting "by type" can provide better compression ratio in some cases.

Note that sorting "by type" has some drawbacks.For example, NTFS volumes use sorting order "by name", so if an archive uses another sorting, then the speed of some operations for files with unusual order can fall on HDD devices (HDDs have low speed for "seek" operations).

If you have such archive, please don't call the 7-Zip developers about it.Instead try to find the program that was used to create the archive and inform the developers of that program that their software is not ZIP-compatible.

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're probably using a *.* wildcard. 7-Zip doesn't use the operating system's wildcard mask parser, and consequently treats *.* as any file that has an extension. To process all files you must use the * wildcard instead or omit the wildcard altogether.

7-Zip stores only relative paths of files (without drive letter prefix).You can change current folder to folder that is common for all files that you want to compress and then you can use relative paths:

32-bit Windows allocates only 2 GB of virtual space per one application. Also that block of 2 GB can be fragmented (for example, by some DLL file), so 7-Zip can't allocate one big contiguous block of virtual space.There are no such limitations in 64-bit Windows. So you can use any dictionary in Windows x64, if you have required amount of physical RAM.

There are some possible cases when archive is corrupted: You can open archive and you can see the list of files, but when you press Extract or Test command, there are some errors: Data Error or CRC Error. When you open archive, you get message "Can not open file 'a.7z' as archive"It's possible to recover some data. Read about recovering procedure:Recover corrupted 7z archive

One way is to use the 7z.dll or 7za.dll (available from sf.net for download). The 7za.dll works via COM interfaces. It, however, doesn't use standard COM interfaces for creating objects. You can find a small example in "CPP\7zip\UI\Client7z" folder in the source code. A full example is 7-Zip itself, since 7-Zip works via this dll also. There are other applications that use 7za.dll such as WinRAR, PowerArchiver and others.

Since 7-Zip is licensed under the GNU LGPL you must follow the rules of that license. In brief, it means that any LGPL'ed code must remain licensed under the LGPL. For instance, you can change the code from 7-Zip or write a wrapper for some codefrom 7-Zip and compile it into a DLL; but, the source code of that DLL (including your modifications / additions / wrapper) must be licensed under the LGPL or GPL.Any other code in your application can be licensed as you wish.This scheme allows users and developers to change LGPL'ed code and recompilethat DLL. That is the idea of free software. Read more here: can also read about the LZMA SDK, which is available under a more liberal license.

py7zr supports algorithms and filters which lzma module and liblzma support,and supports BZip2 and Deflate that are implemented in python core libraries,It also supports ZStandard, Brotli and PPMd with third party libraries.

A feature handling symbolic link is basically compatible with p7zip implementation,but not work with original 7-zip because the original does not implement the feature.py7zr try checking symbolic links strictly and raise ValueError when bad link is requested,but it does not guarantee to block all the bad cases.ZStandard and Brotli is not default methods of 7-zip, so these archives are considerednot to be compatible with original 7-zip on windows/p7zip on linux/mac.Enhanced Deflate is also known as DEFLATE64 TM that is a registered trademark of PKWARE, Inc.Enhanced Deflate is tested only on CPython. It is disabled on PyPy.Not supported algorithmsBCJ2 (Standard lzma module does not provide).InstallYou can install py7zr as usual other libraries using pip.

PackagePurposePyCryptodomex7zAES encryptionPyZstdZStandard compressionPyPPMdPPMd compressionBrotliBrotli compression (CPython)BrotliCFFIBrotli compression (PyPy)inflate64Enhanced deflate compressionpybcjBCJ filtersmultivolumefileMulti-volume archive read/writetexttableCLI formatterPerformanceYou can find a compression and decompression benchmark results at[Github issue]( ) and [wiki page]( )

This library is distributed in the hope that it will be useful,but WITHOUT ANY WARRANTY; without even the implied warranty ofMERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNULesser General Public License for more details.

You should have received a copy of the GNU Lesser General PublicLicense along with this library; if not, write to the Free SoftwareFoundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA

Hi.

I'm archiving heavy important data (on a scale from few to hundred Gb) and I need to nicely compress it to gain disk space.

I chose LZMA as compression format because AFAIK it's the best one adaptated to this goal... but because life can often be malicious, I could only create a few compressed archives before Dolphin (or Ark) suddenly stops the process and send a notification that asserts it was a success but returns a broken link that doesn't lead to anything... because there's no file. I just lost my time.

What the hell?

It even happens to the progress bar to go on a infinite loop with no defined max value, until a) the issue happens again b) it goes back to a defined progress value for a short time.

xz is compressing a data stream, not archiving files. You must first archive files using another tool, e.g. tar. This makes archive scanning and decompression a linear process (slow), however tar stores file attributes better than 7zip.

It worked, but it does not solve my Dolphin-related problem at all. It would be annoying to ignore the Ark-based GUI and use only CLI to compress files.

By the way, with the file command, I noticed that the output archive was considered as...

According to the Github page, Ark is using the 7z binary for all 7-Zip-related archive formats.

LZMA archives, that I made via the Dolphin/Ark GUI, were classified like "LZMA compressed data, streamed"

Your current theory is that ark/dolphin uses some subprocess to compress data and that specific subprocess fails the compression.

To figure whether and which subprocess is used, check the process tree ("ps fax" might be helpful), I'd assume the compression runs long enough for that?

To figure whether it is an actual problem with this specific compression, test the same (entire) data against some other algorithm.

is underspecific or meaningless in this case.

If you used some other algorithm 3 years ago on a 1MB text file, there're obviously a lot of variables when compared to the situation at hand (volume, available disk space and updates across the entire software stack)

3a8082e126