Change file in Zip archive without repacking

Hi All,
I have Zip archive. It contains ~100000 files. I needed to change only one file, without repacking all Zip archive.
How can I do this? Do smb have such situations?

You can't, using Java. I think that there are 3rd-party products that can. Try searching for one.

Similar Messages

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.

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.

How to replace a file in an archive without extracting?

Hello, I need to open up an archive and replace one file with the other. As archive file is and actual .ipa file (I'm just changing its type), I don't want to extract it and then re-zip it and rename it to .ipa.
It's beyond simpleness on Windows OS, but on a Mac you can only see content of an archive and extract any chosen one, but not replacing it directly.
Maybe there are simple terminal commands to do so?
Thank you.

man zip
or see it on the web: https://developer.apple.com/library/mac/DOCUMENTATION/Darwin/Reference/ManPages/ man1/zip.1.html

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.

How to change file type from .zip to .dock

I would like to know how to change the saved file type (.zip) to other file types such as (.txt), (.doc), (.dock) or (.pdf).

It's more complicated than just changing the name of the file to have a different extension. What you have to do is to convert a file from one format to another. To do that you have to use an application that knows how to open the original type and how to write the format of the new type. The application to use for a given combination depends on the combination. For example, the Preview applications knows how to read a JPG file and write the contents to a PDF file.
A ".zip" file is a somewhat different case. A ".zip" file is an "archive" that (generally) contains other files compressed within it. If you double-click on a ZIP file, it should expand into the enclosed files.
If you give specific examples of what you want to convert, people should be able to explain what to do.
By the way, I'm not familiar with a file of type ".dock". What is that?

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)
          }

[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

Drop files out of zip archiv and deliver?

Is it possible to drop a special filetype (exe) or filenames out of an zip archiv? After deleting the unwanted "archiv-members", the archiv should be delivered.
I need this requirement for specific recipients, not as a "global setting".

While it is possible to drop an archive file if the contents contain a certain attribute ( .exe file, filename, etc... ), at this time I am not aware of any way to remove a *single* portion of that archive and deliver the rest of the contents.
I would envision the difficulty would lie in re-assembling the archive correctly, so the recipient did not receive a "broken" file.
-whardison

How do i download and e-mail from a zip drive without opening the file

How do I download and e-mail data from a zip drive without opening the file?

Hi.
If you have a Zip drive, you can handle the file as you would any other file. Copy and paste. Drag and drop. Select and attach as an email attachment.
Zip drive data discs came in two capacities, 100MB and 250MB. So the largest files would not exceed those capacities, depending on the media from which they are pulled.
The trick, I should think, would be finding a working drive that can read the media... and hope that media is not corrupted. Zip media was notorious for failing.
I hope this helps.

To ZIP all files into a single ZIP archive

hi,
Can anybody suggest me how to Zip mutiple files into single Zip archive.

Hi,
use Winzip :).Or jar all your files with JAVA. And then rename the
extension to .zip. In fact a .jar file is a .zip file.
http://java.sun.com/docs/books/tutorial/jar/basics/index.html
Cheers!

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

When a zip file is un-archived, where does it go?

When a zip file is un-archived, where does it go?

Alan
It is in your downloads folder if that is where you saved it to. If you're unsure of where the unzipped file/application is simply open finder and do a search for it. You can also do a Spotlight search for it as well.
Joseph

Corrupt (?) zipped files from "Create Archive"

I am repeatedly having trouble with files I zip using "create archive." Whether it's fonts or images, the recipients are not able to use the files I send (they seem to uncompress, but aren't readable). This is happening often enough that I wonder if there is a problem with the software. I didn't find this question asked when I did a search.
thanks!

Hi, casperr. Welcome to the Discussions.
1. Are the recipients using Windows? If so, you may want to purchase a copy of StuffIt Deluxe, which can create archives that are both Windows-friendly and self-extracting.
2. Have you tried opening the archives you have created with Create Archive to see if the contents of the archive you've created are AOK before sending them? That will help you determine if the problem is on your Mac, with the transmission, or a problem on the other user's computer.
3. You might want to enquire as to how the recipients are unzipping the archives you have sent that they are finding problematic.
Good luck!
Dr. Smoke
Author: Troubleshooting Mac® OS X

Check InputStream (File) if it is a ZIP archive?

How can i check a inputstream (which may be a file but does not have to be) if it is a ZIP stream?

There should be a way to identify it as a Zip stream
(probably starts with "PK\0\0"), so...Wow I never knew that... I just checked a .jar file
and its true.
BTW, the PK, that's from the original pkzip/unzip,
right? That's a blast from the pastYes, and "PK" is the late Phil Katz who invented the zip format.
So if your file (or stream, it makes no difference) starts with those bytes then there is a good chance it is a zip archive. Probably an excellent chance. But you are not guaranteed of that. All the first-couple-of-bytes give you is a sanity check; if they aren't PK etc. then you don't have a zip archive.

Change file in Zip archive without repacking

Similar Messages

Maybe you are looking for