Zip archive problem

Hi everyone,
Is there a way to repair a corrupt zip archive? I have a rather large file, a 2GB movie I want to unzip, but I get an error message with every program I've tried (stuffit, archive, jimzip, zipeg, the unarchiver). When I tried to unzip directly from the terminal, I got the following message:
bad CRC f23db85c (should be 77b37ff6)
It only expands the first 75MB of the file. Any ideas or suggestions?
Thanks!

Hi Davidludwig;
To the best of my knowledge no. I do not believe there is sufficient redundancy in the data after it has been compressed to effect a recovery of data. The CRC is created as the data is compressed into the zip file and then later used to check for corruption. If corruption has occurred as in your case, there is no way to recover it.
I think this is one of the reasons zip files are used for communications and not archives. With communications, if the CRC fails you sent it again. With archive on the other hand, the original is gone by the time the CRC fails hence you lost the archive.
Allan

Similar Messages

Zip archiving problem

I'm having this problem every time I try to zip anything: I get a message that says:
The archive's list of contents cannot be created.
Two friends are having exactly the same problems.
We also can't stablish AFP network connections, and all these problems started the same day.
Is there anybody else with the same problems? Is there some kind of solution?? What could be this? Some Virus?
We are using the same OS X, 10.4.6, and two of the affected iMacs are PPC based, and mine is an Intel one.
See you people, and thanks a lot!
Bye!

Hi, gvcba —
Welcome to Apple Discussions!
This isn't an area in which I have a lot of experience, so I did a little searching about these topics, in an effort to help. But I'm not sure whether what I found matches the specifics of what you're experiencing. It may help if you define the problems in a bit more detail.
(1) Regarding: "I'm having this problem every time I try to zip anything: I get a message that says: "The archive's list of contents cannot be created."Are you using (a) Finder's File »» Create Archive of "foldername" or (b) StuffIt (which version?) or (c) another means in an effort to archive?
If (b), Note that there has been some discussion of StuffIt 10.x issues in various forums — most of which seem to have been resolved by updating to StuffIt version 10.0.2 (PPC) or the StuffIt Universal (Beta) release. For example: in this "StuffIt" thread, problems using some StuffIt Deluxe components were reported to be addressed in the StuffIt Universal (Beta) release. Perhaps reviewing VersionTracker readers' feedback on StuffIt version 10.0.2 would be helpful.
The only case I could find by a quick Google•Mac search for the specific error message you've quoted was a thread about problems encountered [apparently] by users of the "Windows hack" trying to update to OS X 10.4.3 (before Boot Camp Beta was released) — and I presume this isn't relevant.
(2) About: "We also can't [e]stablish AFP network connections, and all these problems started the same day... What could be this? Some Virus?" —— stop thinking about viruses. A specific case (and a "work-around" for it) are discussed in this "10.4.6 AFP issues?" thread. I also found this "10.4.6 AFP & PhotoShop CS2 fix" thread that discusses a successful "work-around" for that case.
I hope this is useful to you. If not, perhaps others can help if you'll describe the problems in a little more detail.
Good luck — and
Regards,
Dean

Windows Explorer misreads large-file .zip archives

   I just spent about 90 minutes trying to report this problem through
the normal support channels with no useful result, so, in desperation,
I'm trying here, in the hope that someone can direct this report to some
useful place.
   There appears to be a bug in the .zip archive reader used by Windows
Explorer in Windows 7 (and up, most likely).
   An Info-ZIP Zip user recently reported a problem with an archive
created using our Zip program. The archive was valid, but it contained
a file which was larger than 4GiB. The complaint was that Windows
Explorer displayed (and, apparently believed) an absurdly large size
value for this large-file archive member. We have since reproduced the
problem.
   The original .zip archive format includes uncompressed and compressed
sizes for archive members (files), and these sizes were stored in 32-bit
fields. This caused problems for files which are larger than 4GiB (or,
on some system types, where signed size values were used, 2GiB). The
solution to this fundamental limitation was to extend the .zip archive
format to allow storage of 64-bit member sizes, when necessary. (PKWARE
identifies this format extension as "Zip64".)
   The .zip archive format includes a mechanism, the "Extra Field", for
storing various kinds of metadata which had no place in the normal
archive file headers. Examples include OS-specific file-attribute data,
such as Finder info and extended attributes for Apple Macintosh; record
format, record size, and record type data for VMS/OpenVMS; universal
file times and/or UID/GID for UNIX(-like) systems; and so on. The Extra
Field is where the 64-bit member sizes are stored, when the fixed 32-bit
size fields are too small.
   An Extra Field has a structure which allows multiple types of extra
data to be included. It comprises one or more "Extra Blocks", each of
which has the following structure:
       Size (bytes) | Description
      --------------+------------
            2       | Type code
            2       | Number of data bytes to follow
        (variable) | Extra block data
   The problem with the .zip archive reader used by Windows Explorer is
that it appears to expect the Extra Block which includes the 64-bit
member sizes (type code = 0x0001) to be the first (or only) Extra Block
in the Extra Field. If some other Extra Block appears at the start of
the Extra Field, then its (non-size) data are being incorrectly
interpreted as the 64-bit sizes, while the actual 64-bit size data,
further along in the Extra Field, are ignored.
   Perhaps the .zip archive _writer_ used by Windows Explorer always
places the Extra Block with the 64-bit sizes in this special location,
but the .zip specification does not demand any particular order or
placement of Extra Blocks in the Extra Field, and other programs
(Info-ZIP Zip, for example) should not be expected to abide by this
artificial restriction. For details, see section "4.5 Extensible data
fields" in the PKWARE APPNOTE:
      http://www.pkware.com/documents/casestudies/APPNOTE.TXT
   A .zip archive reader is expected to consider the Extra Block type
codes, and interpret accordingly the data which follow. In particular,
it's not sufficient to trust that any particular Extra Block will be the
first one in the Extra Field. It's generally safe to ignore any Extra
Block whose type code is not recognized, but it's crucial to scan the
Extra Field, identify each Extra Block, and handle it according to its
type.
   Here are some relatively small (about 14MiB each) test archives which
illustrate the problem:
      http://antinode.info/ftp/info-zip/ms_zip64/test_4g.zip
      http://antinode.info/ftp/info-zip/ms_zip64/test_4g_V.zip
      http://antinode.info/ftp/info-zip/ms_zip64/test_4g_W.zip
   Correct info, from UnZip 6.00 ("unzip -lv"):
Archive: test_4g.zip
Length   Method    Size Cmpr    Date    Time   CRC-32   Name
4362076160 Defl:X 14800839 100% 05-01-2014 15:33 6d8d2ece test_4g.txt
Archive: test_4g_V.zip
Length   Method    Size Cmpr    Date    Time   CRC-32   Name
4362076160 Defl:X 14800839 100% 05-01-2014 15:33 6d8d2ece test_4g.txt
Archive: test_4g_W.zip
Length   Method    Size Cmpr    Date    Time   CRC-32   Name
4362076160 Defl:X 14800839 100% 05-01-2014 15:33 6d8d2ece test_4g.txt
(In these reports, "Length" is the uncompressed size; "Size" is the
compressed size.)
   Incorrect info, from (Windows 7) Windows Explorer:
Archive        Name          Compressed size   Size
test_4g.zip    test_4g.txt         14,454 KB   562,951,376,907,238 KB
test_4g_V.zip test_4g.txt         14,454 KB   8,796,110,221,518 KB
test_4g_W.zip test_4g.txt         14,454 KB   1,464,940,363,777 KB
   Faced with these unrealistic sizes, Windows Explorer refuses to
extract the member file, for lack of (petabytes of) free disk space.
   The archive test_4g.zip has the following Extra Blocks: universal
time (type = 0x5455) and 64-bit sizes (type = 0x0001). test_4g_V.zip
has: PWWARE VMS (type = 0x000c) and 64-bit sizes (type = 0x0001).
test_4g_W.zip has: NT security descriptor (type = 0x4453), universal
time (type = 0x5455), and 64-bit sizes (type = 0x0001). Obviously,
Info-ZIP UnZip has no trouble correctly finding the 64-bit size info in
these archives, but Windows Explorer is clearly confused. (Note that
"1,464,940,363,777 KB" translates to 0x0005545500000400 (bytes), and
"0x00055455" looks exactly like the size, "0x0005" and the type code
"0x5455" for a "UT" universal time Extra Block, which was present in
that archive. This is consistent with the hypothesis that the wrong
data in the Extra Field are being interpreted as the 64-bit size data.)
   Without being able to see the source code involved here, it's hard to
know exactly what it's doing wrong, but it does appear that the .zip
reader used by Windows Explorer is using a very (too) simple-minded
method to extract 64-bit size data from the Extra Field, causing it to
get bad data from a properly formed archive.
   I suspect that the engineer involved will have little trouble finding
and fixing the code which parses an Extra Field to extract the 64-bit
sizes correctly, but if anyone has any questions, we'd be happy to help.
   For the Info-ZIP (http://info-zip.org/) team,
   Steven Schweda

> We can't get the source (info-zip) program for test.
   I don't know why you would need to, but yes, you can:
      http://www.info-zip.org/
      ftp://ftp.info-zip.org/pub/infozip/src/
You can also get pre-built executables for Windows:
      ftp://ftp.info-zip.org/pub/infozip/win32/unz600xn.exe
      ftp://ftp.info-zip.org/pub/infozip/win32/zip300xn.zip
> In addition, since other zip application runs correctly. Since it should
> be your software itself issue.
   You seem to misunderstand the situation. The facts are these:
   1. For your convenience, I've provided three test archives, each of
which includes a file larger than 4GiB. These archives are valid.
   2. Info-ZIP UnZip (version 6.00 or newer) can process these archives
correctly. This is consistent with the fact that these archives are
valid.
   3. Programs from other vendors can process these archives correctly.
I've supplied a screenshot showing one of them (7-Zip) doing so, as you
requested. This is consistent with the fact that these archives are
valid.
   4. Windows Explorer (on Windows 7) cannot process these archives
correctly, apparently because it misreads the (Zip64) file size data.
I've supplied a screenshot of Windows Explorer showing the bad file size
it gets, and the failure that occurs when one tries to use it to extract
the file from one of these archives, as you requested. This is
consistent with the fact that there's a bug in the .zip reader used by
Windows Explorer.
   Yes, "other zip application runs correctly." Info-ZIP UnZip runs
correctly. Only Windows Explorer does _not_ run correctly.

Files in ZIP Archive not visible in XP explorer

I have a strange problem. I'm sure the solution is something simple, but I seem to be overlooking it. I am creating a .zip archive from within my Java app, zipping up 5-10 straight text files. From what I can tell the file gets created successfully. After the .zip file is created, I can do a jar -tf on the file and it will show them all to me. I can also programatically get a list of the files in the archive and it all looks correct. However, when I try opening the archive file from the Windows XP file explorer (or extracting it to a location) it says that there are no objects in the archive.
Here is the code I am using to create the zip file:
   byte[] buf = new byte[1024];
   try {
      String outputFilename = "somefile.zip"; // The output archive
      ZipOutputStream outStream = new ZipOutputStream(new FileOutputStream(outputFilename));
      System.out.println("createZip: zipping "+_files.length+" files.");
      // _files is an array of c:\somedir\somefile.txt file listings
      for (int i=0; i<_files.length; i++) {
        System.out.println("Adding entry: "+_files);
FileInputStream in = new FileInputStream(_files[i]);
outStream.putNextEntry(new ZipEntry(_files[i]));
int len;
while ((len = in.read(buf)) > 0) {
outStream.write(buf,0,len);
outStream.closeEntry();
in.close();
outStream.finish();
outStream.close();
rv = true;
// ... catch, return value, etc.
Any suggestions or hints would be greatly appreciated..

We had a similar problem
It turned out to be a feature and not a bug
Actually 'vanilla' XP handles those files and is able to open them and it seems that the problem appears only after updating the XP to fix the vulnerability described in:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS02-054.asp
What we have determined is that if the zip file contains '/' at the begining of the path - the compressed folder utility will refuse to open it and will show only a blank pane in explorer. Removing the '/' from path in zip file solves the problem on updated Windows XP.

Automate renaming files within zip archive

I have a large number of files where I need to do the following:
Change the file extension to .zip. (The files are zip archives but with a special extension, and all of the files have their own extension, ie .xx01, .xx02, etc...)
Extract the zip file.
Rename a file within. (Alternatively, it'd be great to be able to rename the file without extracting the zip file.)
Recompress the file.
Set the file extension back to what it was.
I've been playing around in Automator to see if I could create a workflow that would do some or all of this. I've figured out changing the file extension, and Automator has an action to compress a zip file, but the other parts are eluding me.
Does anyone know a way to make this process a little less labor intensive? I'd prefer to automate the whole thing, but even just some way to rename a file in a .zip archive without extracting it first would be hugely helpful. (I know this is possible under Windows.)
I'm comfortable with delving into new territory in Automator, AppleScript, or shell scripts to make this easier.
Thanks!

We had a similar problem
It turned out to be a feature and not a bug
Actually 'vanilla' XP handles those files and is able to open them and it seems that the problem appears only after updating the XP to fix the vulnerability described in:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS02-054.asp
What we have determined is that if the zip file contains '/' at the begining of the path - the compressed folder utility will refuse to open it and will show only a blank pane in explorer. Removing the '/' from path in zip file solves the problem on updated Windows XP.

Deleting files that have been extracted from a zip archive

Can we PLEASE get an update that will allow us to delete the files that were extracted from a zip archive. This is ridiculous. A quick google brings back loads of threads all over the place about people who want to be able to delete files but can't because of some daft bug.
How are RIM not aware of this? Do they not care?

There is a bug in the .zip decompressor used by the native file manager. It incorrectly applies file permissions sometimes stored in the archive to the extracted files, preventing them from being deleted by us mere mortals. Once extracted, there's nothing you can do.
<plug>
You could, of course, use Files & Folders to extract your zip files, which doesn't suffer from this problem.
</plug>
Files & Folders, the unified file & cloud manager for PlayBook and BB10 with SkyDrive, SugarSync, Box, Dropbox, Google Drive, Google Docs. Free 3-day trial! - Jon Webb - Innovatology - Utrecht, Netherlands

Windows fails to open Samba ZIP archives with names over 8 characters

I have an XServe running OS X Leopard in Advanced mode. It is running Samba in order to provide file sharing services to Windows clients within our network.
I have Vista running in VMWare Fusion, accessing a file-share on the Leopard server via Samba. I have stored a .exe file and a .zip file on the share. When I try to access these files, I am able to successfully access the .exe but not the .zip.
The error I receive (upon attempting to open the ZIP archive) is:
"Windows cannot open the folder.
The Compressed (zipped) Folder 'Z:\1234abcde.zip' is invalid."
Sometimes copying the file to the local desktop succeeds (allowing me to open the file from there) and sometimes it fails with a message about an "invalid file handle".
If I shorten the name of the zip archive to only eight characters (plus .zip) everything works. The executable, which also has a long name, never presents any problems (I am able to double-click and run it, as well as copy it).
I have no problem accessing these files locally on the server or from a Mac OS X Leopard client (via Samba or AFP).
Any ideas?
Thanks,
Erik

Hi !
Open the setup page of the router
Click on wireless tab
Changed the SSID,channel
Save setting
U will a sub tab Advance wireless setting
Change the beakon interval to 50
Change the RTS threshold to 2304
Change the Fragementation threshold to 2304
save setting !
It will connect automatically !
Network Security Administrator (EC Council)
linksysfirmwares.googlepages.com/

Since downloading Pages 5.0.1 on iPad I cannot open any pages documents. The fault reads= "Newsletter 2013.12.08.pages.zip : zip archive - 541KB"

Since downloading Pages 5.0.1 on iPad I cannot open any pages documents. The fault reads= "Newsletter 2013.12.08.pages.zip : zip archive - 541KB"

Did a fresh install and still having the same problem. Giving up now. Mod can now close this thread

Need help in creating a Zip archive through Java

I need some files existing a folder.
When I use ZipOutputStream to zip the files, do I need to give the entire path to each of the files to add the file to the zip archive?
For example here is the folder structure.
C:
->Folder1
---->Folder2
------>File1
------>File2
---->File3
---->File4
Here should I pass the entire path of Each file to the ZipOutputStream?
Can any one please give me an example of creating a zip archive of the above file structure.
Thanks,
Ramesh

Hi,
I atleast need the following:
I want to add a file "pres.txt" to an existing zip archive "test..zip". This file "pres.txt" already exists in the zip archive, but is a modified one.
Can any one please help.
Thanks,
Ramesh

Create a new directory in existing Zip archive

Hello Every One
I want create a new folder in existing Zip archive. Can any one help in this regard.
Thanks
Edited by: SatishBejgum on Dec 18, 2007 12:42 AM

Delete the ZIP, write a new one. You can't modify an existing archive.

Loading a text file in a gzip or zip archive using an applet to a String

How do I load a text file in a gzip or zip archive using an applet to a String, not a byte array? Give me both gzip and zip examples.

This doesn't work:
          try
               java.net.URL url = new java.net.URL(getCodeBase() + filename);
               inputStream = new java.io.BufferedInputStream(url.openStream());
               if (filename.toLowerCase().endsWith(".txt.gz"))
                    inputStream = (java.io.InputStream)(new java.util.zip.GZIPInputStream(inputStream));
               else if (filename.toLowerCase().endsWith(".zip"))
                    java.util.zip.ZipInputStream zipInputStream = new java.util.zip.ZipInputStream(inputStream);
                    java.util.zip.ZipEntry zipEntry = zipInputStream.getNextEntry();
                    while (zipEntry != null && (zipEntry.isDirectory() || !zipEntry.getName().toLowerCase().endsWith(".txt")))
                         zipEntry = zipInputStream.getNextEntry();
                    if (zipEntry == null)
                         zipInputStream.close();
                         inputStream.close();
                         return "";
                    inputStream = zipInputStream;
               else
               byte bytes[] = new byte[10000000];
               byte s;
               int i = 0;
               while (((s = inputStream.read())) != null)
                    bytes[i++] = s;
               inputStream.close();
        catch (Exception e)
          }

Adobe Bridge CS5.1 crashes if directory contains .zip archive

Every time I try to open a directory that contains .zip archive in Adobe Bridge CS5.1 it crashes. This started to happen after Mountain Lion upgrade.
It crashes even when I generate .zip archive in a directory that is already opened in Bridge.
Is it related to some new Mountain Lion "security feature" that can be turned off? My computers only purpose is running Adobe Creative Suite so this is pretty big issue. Browsing directories in Bridge is like walking through the mine field, you newer know where .zip archive is waiting.

Yep, same here. Running Adobe bridge CS5.1, upgraded to Mountain Lion yesterday. Navigated to folder that contained a zip file and Bridge crashed. I removed the zip file, launched Bridge again,and went to that same folder. Worked perfectly. On a hunch, I dragged a zip file back into that folder in Bridge, and *WHAP* down she goes again.
Looks like we wait for a fix. *sigh*
Unless...File type association somehow comes into it? Interesting, I just checked (it's under Preferences) and neither a zip file or a doc file is in the list.
Furthermore, there doesn't seem to be any way to add a new file type. Hm. Don't know if it has anything to do with the crashing, but man, what a pain this is!

How to recover a zip archive?

Dear all,
I'm trying to open a zip archive I created but I've got the message "Error 1-Operation not permitted".
I don't know if it is corrupted or something else. It's an archive with 3 or 4 mov and wmv files on it.
Could you suggest me any name of software that can recover it? Or some trick to force the opening of it? I've tried system's Archive Utility, Stuffit...
Thanks in advance.
Ken

Ken Ponzio wrote:
Arigato Kenichi.
But unfortunately I have only mac os sys in my studio! No windows...
I'already saw there are some windoze zip recover sw but I've not found a mac soft...
thanks anyway
ken
Can you email or FTP it to a Windows user you know? You could also use iDisk or MobilMe to do the same. The Windows user could extract/repair the archive and return it to you.

I have an iPhone 5S and I can't open photos that are emailed to me. It just says zip archive when I click on the jpg. Help?

I Have an iPhone 5S and I can't open photos that emailed to me. It just says Zip archive when I click on the JPG file to download it. Help?

whoever is emailing you the photos is sending them as a .zip file not a .jpg most likely because there is more than one photo. unfortunately iPhone does not have a .zip file reader so whoever is emailing the photos has to make sure they are not zip ing them and resend them as .jpg files. (usually gmail tries to convert several images into .zip files)

After Migration to Server 2012 R2 One Zip Archive (7.08 mb) Downloads Empty

I recently migrated from Server 2008 R2 to 2012 R2. I offer a number of web application as zip archives and Dreamweaver Extension installer packages .mxp. I have one zip archive that's empty when downloaded with size 0. Out of all the files served
the issue only exists with this one file. All the other files regardless of .zip or .mxp work correctly. I think it may be a size related issue. The .zip file that is empty is 7.08 mb and the others are much smaller. I've tried deleting the existing file
and uploading a new one with and without a file name change and still get same results. Here's the code.
I'm thinking I may need to allow the larger file download. Does anyone know how to fix this?
Response.Buffer=true
On Error Resume Next
'Create a stream object
Dim mxp_downloadStream
Set mxp_downloadStream = Server.CreateObject("ADODB.Stream")
mxp_downloadStream.Type = 1
mxp_downloadStream.Open
mxp_downloadStream.LoadFromFile Server.Mappath("../downloads/dwmx_extensions/" & (rs_mxp.Fields.Item("MXP_DL_Path").Value) & "")
If Err.number = 0 Then
Response.Clear
Response.ContentType = "application/octet-stream"
Response.AddHeader "Content-Disposition", "attachment; filename=" & (rs_mxp.Fields.Item("MXP_DL_Path").Value) & ""
Response.AddHeader "Content-Transfer-Encoding","binary"
Response.BinaryWrite mxp_downloadStream.Read
mxp_downloadStream.Close
Set mxp_downloadStream = Nothing
Response.End()
End If

YOu are asking a quesiton about ASP on a web server. YOu need to post in the web server forum for this. Thisis not a web scripting forum.
Try here: http://forums.iis.net/
¯\_(ツ)_/¯

Zip archive problem

Similar Messages

Maybe you are looking for