Using TrueZIP, is there a way to open and modify an existing ZIP file from a stream (it may of course be outputted using another stream)?
I have code for modifying a ZIP that works perfectly as long as I work on an existing real ZIP file on the file system but I have a requirement that all temporary files need to be encrypted while stored on disk. In most part of our application this is easy to achieve (using CipherOutputStream and CipherInputStream) but I have one function that uses TrueZIP to update an existing ZIP file. This part obviously fails if the file is encrypted.
The ZIP files will be consumed by proprietary applications that do not support encryption so using the encryption that is part of the ZIP specification isn't possible.
The reason we are using TrueZIP is that we need the support for Zip64 (which I know is included in Java 7 but we cannot switch right now).
No, an archive file must be stored in accessible file system to use it with TrueZIP. But you have a number of other options:
TrueZIP uses instances of the IOPoolService interface to manage temporary files. You could provide your own implementation which encrypts all temporary files or maybe even just stores them on the heap (if they are small). Have a look at the TrueZIP Driver FILE to see the reference implementation.
You could use the ParanoidZipRaesDriver to use RAES encrypted ZIP files. This driver ensures that no unencrypted temporary files are used by limiting the number of concurrent threads for writing an archive file to one.
You could use the standard ZIP drivers with FsOutputOption.ENCRYPT to switch on WinZip AES encryption. To ensure that no unencrypted temporary files are used, you could then override the ZipDriver.newOutputSocket method just like the ParanoidZipRaesDriver does.
Related
In my project which deals with SAS
we have risk binary files of extension .rskcdesc
I have been looking but not able to find any python Java library which can read it.
I need to automate data checks via Backend process, hence need a way to decode these files.
Any suggestions?
Rohit,
I don't have SAS Risk but SAS has been using zip for some of their files (like EG projects). Try renaming the file extension to .zip and open it. It may be comprised of XML files, similar to EG.
I have zipped and protected a file with a password.
Now I need to retrieve the file back with java. So I need to unlock the password and unzip with Java to make a proper connection to the file.
My first Questions is: Does Java unzip and unlock the zipped file on the local drive? (So no point protecting it?).
I have read all about encryption, but really searching for the easiest way here.
This link: http://blog.alutam.com/2009/10/31/reading-password-protected-zip-files-in-java/
My second Question is about the link above: I cannot find the lines where he is pointing to his zipped file on the local drive+ the password he uses to unlock the file (is it hardcoded?)
Thank you
You may want to have a look on Zip4j
Key features:
Create, Add, Extract, Update, Remove files from a Zip file
Read/Write password protected Zip files
Supports AES 128/256 Encryption
Supports Standard Zip Encryption
Supports Zip64 format
Supports Store (No Compression) and Deflate compression method
Create or extract files from Split Zip files (Ex: z01, z02,...zip)
Supports Unicode file names
Progress Monitor
I've got many files that I want to store in a single archive file. My first approach was to store the files in a gzipped tarball. The problem is, that I've to rewrite the whole archive if a single file is added.
I could get rid of the gzip compression, but adding a file would still be expensive.
What other archive format would you suggest that allows fast append operations?
The ZIP file format was designed to allow appends without a total re-write and is ubiquitous, even on Unix.
ZIP and TAR fomats (and the old AR format) allow file append without a full rewrite. However:
The Java archive classes DO NOT support this mode of operation.
File append is likely to result in multiple copies of a file in the archive if you append an existing file.
The ZIP and AR formats have a directory that needs to be rewritten following a file append operation. The standard utilities take precautions when rewriting the directory, but it is possible in theory that you may end up with an archive with a missing or corrupted directory if the append fails.
There are 2 servers that are geographically very far from each other.
One server does file processing, then saves the processed file in a directory:
c:\processed\
Files can be 100-1GB in size.
The 2nd server is to download these files.
What techniques can I use to check if the file correctly downloaded?
Is a checksum all I need to do? will it hash according to the contents of the file or just the file attributes? (or what is best practise)
If the file is 1GB, will creating the checksum take a long time?
Checksum is fine to make sure that the downloaded data matches the source data. For a discussion of making it fast, see What is the fastest way to create a checksum for large files in C#.
I have a directory with a name that contains Japanese characters, and I need to use the zip utils in java.util.zip to write it to a zip file. Writing the zip file succeeds, but when I open the resulting zip file with either Windows' built-in compressed file utility or 7-Zip, the directory with Japanese characters in the name appears as a bunch of garbage characters. I do have the Japanese/East Asian language pack installed on my system -- I can create directories with Japanese names, so that isn't the issue.
Interestingly, if I write a separate script to read the resulting zip file using java.util.zip, the directory name is correct, and I can extract the contents of the zip into appropriately named directories, with Japanese characters. But I can't do this using the commercial zip tools that I've tried, which is undoubtedly what our customers will want to do.
Any ideas about what is causing this problem, and how I can work around it?
I know about this bug, but I still need a workaround for this case.
TrueZIP claims to do this better:
The J2SE API always uses UTF-8 (eight
bit Unicode character set) for entry
names and comments instead of CP437
(a.k.a. IBM437, the genuine IBM-PC
character set), which is used by the
de-facto standard PKZIP from PKWARE.
As a result, you cannot read or write
ZIP files with international entry
file names such as e.g. "täscht.txt"
in a ZIP file created by a (southern)
German.
[description of other problems omitted]
The TrueZIP Library has been developed to overcome these limitations/disadvantages.
Miracles indeed happen, and Sun/Oracle did really fix the long-living bug/rfe:
Now it's possible to [set up filename encodings upon creating][1] the zip file/stream (requires Java 7).
[1]: http://download.java.net/jdk7/docs/api/java/util/zip/ZipOutputStream.html#ZipOutputStream(java.io.OutputStream, java.nio.charset.Charset)
If java.util.zip still behaves as this post describes, I'm not sure if it is possible (with the built-in classes). I have seen Chilkat's Java Zip library mentioned before as a way to get this to work, but have never used it.