The Zip4J API provides a convenient method for adding a streamed entry to a zip file:
ZipFile.addStream(InputStream stream, ZipParameters pars)
There does not appear to be a method of specifying the 'file permissions' or 'default file permissions' on instances of either the ZipFile or the ZipParameter classes.
The default behaviour is to have all file properties set to false on the entry, which on a unix system, means that there is no read, write, or execute permissions for owner, group, and other. This is inconvenient. I would like to set at least the read permission flag for the owner.
Is there a means for setting the file permissions on a 'streamed' zip file entry (ie one added using the ZipFile.addStream method?
If not (1) is there a means for adding the file permission after the entry has been created (which is actually stored in the underpinning zip-file on disk - see additional information for this caveat)?
Additional Information
Note, once a stream entry has been added to a Zip file it is possible to get and set the file property information from its header data, which can be obtained using the ZipFile.getHeader(entryName) method. However, setting the file permission values using this API does not affect the underpinning zip file directly. Further, there appears to be no way of saving the updated header information to disk (though I might be missing something).
For reference the methods for getting and setting file attributes are:
byte[] FileHeader.getInternalFileAttributes()
void FileHeader.setInternalFileAttributes(byte[] attributes)
byte[] FileHeader.getExternalFileAttributes()
void FileHeader.setExternalFileAttributes(byte[] attributes)
Digging into the zip4j code, indicates that these file attributes are stored in a 4-byte array, where the bits in bytes 2 and 3 (starting from byte 0) represent the unix file permission bits. This is found in the net.lingala.zip4j.util.FileUtils class's apply posix file attributes.
Potential Workaround (which I am trying to avoid)
One workaround that I can see is writing the data from the stream to a temporary file, ensuring that file has the wanted permissions, adding the file to the zip archive, and then removing the temporary file (as it has served its purpose). This approach assumes that the on disk file permissions are correctly maintained, which appears to be the case, when on a 'posix system'.
I would prefer not to use this approach.
I had this same error, I was using version 2.6.1 and then I found this issue: Unix permissions are messed up It was fixed for version 2.6.2 and up. Just adding standard permissions when running in a Linux Box, not letting you as a user to change those. Check if that version is useful for you.