If you need to preserve existing permissions then it's probably easiest to use <exec> to run the native zip/tar on your platform.
If you only need to set permissions on certain files then you can use a nested <zipfileset> to manually set permissions on those files in the archive. Given that Java does not (currently) have a notion of file permissions, it's unreasonable to expect Java code for *any* archive format to preserve permissions. Ant makes a decent compromise with <zipfileset>, but until JSR 203 is delivered (http://www.jcp.org/en/jsr/detail?id=203) I don't know what else Ant can do. -- Jeffrey E. Care ([EMAIL PROTECTED]) WebSphere v7 Release Engineer WebSphere Build Tooling Lead (Project Mantis) EJ Ciramella <[EMAIL PROTECTED]> wrote on 08/09/2005 09:41:13 AM: > At the top of the zip task definition, it says this: > > "Note that file permissions will not be stored in the resulting > zipfile." > > If you need to store permissions, try tar or exec to use "zip". > > > On Aug 9, 2005, at 9:40 AM, [EMAIL PROTECTED] wrote: > > > Hello all, > > > > I need to zip a the contents of a folder on Mac OSX (10.[3|4]) > > Unfortunatly permissions are broken (executables are no longer > > executable) after I unpack my zipped components and empty > > directories are gone. This breaks my deliverables. > > > > If I call zip on the command line I have no such poblems. Can I use > > the ant zip task and keep the original permissions or do I need to > > wrap teh zip task in an exec-task? > > > > Is this a bug in the zip-task? > > > > here is my cpde: > > <zip destfile="${archiveFullPath}${buildNumber}.zip" basedir="$ > > {feature.base}" excludes=".DS_Store,**/*test*/**"/> > > > > thanks for help. > > > > jacques > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > >
