Salvage from Bad Zip Archive?

Is there any way to salvage the contents of a bad zip archive? I've got an archive of all of my AppleScripts in an archive that isn't unarchiving. The error message is saying, "Unable to unarchive "AppleScripts.zip" into "Desktop" (Error 2 - No such file or directory.)" Even if I can only recover some of the files, it will be better than nothing.
iMac G5 20" Mac OS X (10.4.4)

Does zipinfo AppleScripts.zip give any information?
How about file AppleScripts.zip ?
unzip -d <directory> AppleScripts.zip will let you unzip to a specified directory, in case the archive is trying to create a directory that it is not allowed to.
Also, xxd AppleScripts.zip | more will let you look at the binary data - in an archive I have, I see at the top:
0000000: 504b 0304 1400 0800 0800 6f4e a332 0000 PK........oN.2..
0000010: 0000 0000 0000 0000 0000 0800 1000 3239 ..............29
0000020: 3762 2e70 6466 5558 0c00 ab62 c643 e281 7b.pdfUX...b.C..
and the end of the archive looks like an index to the files in the archive.
Hope that helps give some clues what is wrong.
Boyd

Similar Messages

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

How to extract single file from multipart zip archives?

Hello,
I have a 10 parts of zip files that contains single file. When I extracted these, each program taking an action seperatly to each parts and gave me 10 files in a different folders. In a Windows, it is so simple. Winzip,winrar automaticaly discovering that are the parts of a single file and give me that.
My question is simple: How to extract single file from a multipart zip/rar archives ?
I know a way in "Terminal" but it is not comfortable for big parts.

I tried with UnArchiver but it extracted each file seperately like showen in a photo

Delete an entry from a ZIP archive

Hi,
Does anyone know how to delete a zipentry from a zipfile?
G.

Yes. Recreate the ZIP file without writing that special entry... (You can't change or delete ZIP entries with the Java classes, and I'm not sure whether it's possible at all).

How To Unzip files from Compress Zip Archive Folder?

Hi Friends,
I had compressed my docx files or images files in zip folder last month but unfortunately that folder has corrupted or damaged due to malware infections. But I am not
sure about that what reason behind of zip file get corrupt and inaccessible. If anyone knows about such tools which repair corrupt zip files quickly then shares with me that software information detail.
Thanks

Also, the Microsoft Community/Answers forums might be of help. We cannot move this question there but I got these hits there when I searched on "repair zip":
http://answers.microsoft.com/en-us/search/search?SearchTerm=repair+zip&CurrentScope.ForumName=&CurrentScope.Filter=&ContentTypeScope=&x=0&y=0
Or you can ask here (select your OS):
http://answers.microsoft.com/en-us/windows/forum/files?tab=Threads
Richard Mueller - MVP Directory Services

What tot do with new scripts (ssodatan etc.) from Portal306-308upg_nt.zip archive

Applying the upgrade script from Portal 3.0.7 to 3.0.8 as documented went without errors. But...
The zip archive Portal306-308upg_nt.zip containing the Portal 308 upgrade scripts also has a lot of additional files, like ssodatan, ssodatax and much, much more, that are not installed into the iAS/Portal software tree.
The scripts are newer and sometimes larger then the ones present.
So, what to do with them? I couldn't find any info on these, so I guess it's OK to just toss them away? Probably not. But where should I put them - the directory structure in the archive is quite different from the installed software tree.
Should I keep my existing scripts?
If the new ones are not needed with a migrated portal, why are they included in the upgrade scripts archive?
null

Applying the upgrade script from Portal 3.0.7 to 3.0.8 as documented went without errors. But...
The zip archive Portal306-308upg_nt.zip containing the Portal 308 upgrade scripts also has a lot of additional files, like ssodatan, ssodatax and much, much more, that are not installed into the iAS/Portal software tree.
The scripts are newer and sometimes larger then the ones present.
So, what to do with them? I couldn't find any info on these, so I guess it's OK to just toss them away? Probably not. But where should I put them - the directory structure in the archive is quite different from the installed software tree.
Should I keep my existing scripts?
If the new ones are not needed with a migrated portal, why are they included in the upgrade scripts archive?
null

Domain configuration with Weblogic 12c from ZIP archive

Hi,
for development purposes I have set up an Ubuntu Linux system and installed Weblogic 12.1.3 from ZIP archive following the instructions added with the archive (Oracle Fusion Middleware Software Downloads).
But coming to the point where I want to create the domain, the documentation gets vague and I don't know exactly what to do and why the domain is not and no more scripts are created.
Documentation states:
It is recommended that you create domains outside the MW_HOME.
   Linux
    $ mkdir /home/myhome/mydomain
    $ cd /home/myhome/mydomain
    $ $JAVA_HOME/bin/java $JAVA_OPTIONS -Xmx1024m -XX:MaxPermSize=256m weblogic.Server
So I did the following (normal user is named oracle):
$ mkdir /home/oracle/chkdom
$ cd /home/oracle/chkdom
$ sudo su
$ source /etc/profile
$ $JAVA_HOME/bin/java -Xmx1024m -XX:MaxPermSize=256m weblogic.Server
Weblogic Server starts and the directory structure is created. I am prompted for user credentials to start Weblogic server. But not more than the following output happens:
No config.xml was found.
Would you like the server to create a default configuration and boot? (y/n): y
<06.11.2014 22:54 Uhr MEZ> <Info> <Management> <BEA-140013> </home/oracle/chkdom/config not found>
<06.11.2014 22:54 Uhr MEZ> <Info> <Management> <BEA-141254> <Generating new domain directory in /home/oracle/chkdom.>
What's going wrong?

Okay, forget my posting.
I had to wait more than half an hour and domain is created.

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.

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

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.

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] Append files to an existing archive

Hi to all,
I have an existing file that contains a ZIP archive. I want to add some files to this archive. I have seen in another thread that it's mandatory to read all the structures and construct a new zip file in order to add other files?
Is it true?
In this thread, someone proposes a method that performs this job
<quote>
      * Loads a zip file for appending files
      * @param file The old zip archive
      * @param newFile The new zip archive
      * NOTE: This method will write a new file and data to an archive, to
             * write an existing file, we must first read the data frm the file,
      * then you could call this method.
     public ZipOutputStream loadZipFile(File file, File newFile)
       ZipOutputStream zipOutput = null;
       ZipFile zipFile = null;
       Enumeration zippedFiles = null;
       ZipEntry currEntry = null;
       ZipEntry entry = null;
       try {
          zipFile = new ZipFile( file.getAbsolutePath() );
          //get an enumeration of all existing entries
          zippedFiles = zipFile.entries();
          //create your output zip file
          zipOutput = new ZipOutputStream(new FileOutputStream (newFile));
          //Get all the data out of the previously zipped files and write it to a new ZipEntry to go into a new file archive
          while (zippedFiles.hasMoreElements())
               //Retrieve entry of existing files
               currEntry = (ZipEntry)zippedFiles.nextElement();
               //Read data from existing file
               BufferedReader reader = new BufferedReader( new InputStreamReader( zipFile.getInputStream( currEntry ) ) );
               String currentLine = null;
               StringBuffer buffer = new StringBuffer();
               while( (currentLine = reader.readLine() ) != null )
                    buffer.append( currentLine);
               //Commit the data
               zipOutput.putNextEntry(new ZipEntry(currEntry.getName()) ) ;
               zipOutput.write (buffer.toString().getBytes() );
               zipOutput.flush();
               zipOutput.closeEntry();
          //Close the old zip file
          zipFile.close();
          return zipOutput;
        catch (Exception e)
             Logger.error("LoadZipFile", e);
             System.out.println("Fatal error: "+e);
        return null;
}</quote>
It runs fine but all the file contained in the archive are on a singlie line.
E.g. I have a text file in the original archive. When adding another stuff in the archive and by using this method, my orignal text file has its content on only one line.
Could someone help with this bug?
Kind regards,
St�phane

yes it is true. You can only create a new archive with the added file(s) inside, there is nothing to happen an existing file to an existing zip file.
Good luck

Change of PO Download File Name from SUSDOC.zip

Hello All,
In SRM-SUS when downloading the files, I want to change the name from SUSDOC.zip to the PO number.zip.
The BADI BBP_SUS_DOWNLD_FILES can be used to change the name of the files inside the SUSDOC.ZIP file(I guess)
Any idea to do the name change for the zip file?
I will award the points once answered.
Thank you.
Palaniappan

Are you trying to (a) change the file name but continue to use the same file or (b) make a copy of the original file and change the name of the new file?
In Adobe Reader for iOS 11.3.0 (the latest version as of May 24, 2014),
Go to the Reader home screen.
Tap Documents in the left pane.
Tap Edit in the upper right corner.
Select the file that you want to (a) rename or (b) duplicate.
Tap (a) the Rename icon
or (b) the Duplicate/Move icon and select Duplicate from the menu.
(b) Optionally, rename the duplicated file by repeating Steps 3-5.
Tap Edit in the upper right corner again.
Select the file that you want to save to Acrobat.com.
Tap the following icon and select Save to Acrobat.com

Calendar portlet - bad zip file

Please replace the zip file for the calendar portlet. CRC error - premature end of file reached.
Thanks.

Sue,
I've downloaded the Calendar portlet - June PDK. I am using WinZip 8.0
The zip file opens, however when extracting the contents I get:
"Error in file #1: bad Zip file offset(Error local header signature not found): disk #1 offset:97."
"Error in file #2: bad Zip file offset(Error local header signature not found): disk #2 offset:567." ... and it shows missing header signatures for the rest of the files. I've just downloaded the calendar portlet again (12:45PM EST) and I get the same message. I have tried that on 5 different computers and I get the same message. The test shows that the archive is OK, but when you attempt to extract the files you get the error messages above.
--George
P.S. I've tried extracting the files with WinAce and WinRar and I get the same errors.

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.

Salvage from Bad Zip Archive?

Similar Messages

Maybe you are looking for