Bug 41985 - Zip task doesnt pick up the read-only state of files when adding
Summary: Zip task doesnt pick up the read-only state of files when adding
Status: NEW
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.7.0
Hardware: Other Windows Server 2003
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Ant Notifications List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-03-29 10:57 UTC by Ofir Daniel
Modified: 2008-11-24 03:58 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ofir Daniel 2007-03-29 10:57:34 UTC
When running the ZIP task it changes the file attributes from Read Only to 
R/W, this should not happen, the original file attributes should be preserved.
Comment 1 Steve Loughran 2007-04-02 02:12:55 UTC
Do you mean, when <zip> creates a new file, it creates it with the default
permissions of the user, rather than those of whatever the file was in place?

if so, I dont think we're going to change it. Your build files should be
designed to work cross platform, regardless of whether the output files should
exist or not. If you want to set the permissions after a <zip>, use <chmod>
Comment 2 Ofir Daniel 2007-04-05 03:55:44 UTC
(In reply to comment #0)
> When running the ZIP task it changes the file attributes from Read Only to 
> R/W, this should not happen, the original file attributes should be 
preserved.

First, to make sure its clear - I am refering to the files WITHIN the zip file 
and not to the attributes of the zip file itself. The files contained in the 
zip are NOT perserving their original attributes (Read Only) and they become 
Read/Write, you can see this after you extract the zip.

Second, the problem is appearing in Windows OS (I have not tested on UNIX), 
since in Windows you cannot grant default attributes to a new file created 
(i.e. Read Only), each file created appears with R/W.

I assume that the problem is in ANT <zip> task since if I use other zip 
software (such as winzip command line tool) the files' attributes are 
perserved within the zip file, it can be seen after they are being extracted.
Comment 3 Steve Loughran 2007-04-05 14:08:30 UTC
ahh, now the bugrep makes sense. Changing the title to use the terminology of
the team.
Comment 4 Ofir Daniel 2007-04-06 06:06:21 UTC
I think the title is misleading, I have encountered this when I INITIALLY 
archived a folder containing files, not during an update of an existing zip 
file.
Comment 5 Steve Loughran 2007-04-10 02:24:23 UTC
Ofir. when ant creates a <zip> file from all files in a directory, it will not
pick up any permissions from the files in the filesystem.

That is, if you have a file in the filesys marked read-only or exec, when it
gets into the zip it will have R/W permissions. We do not read the filesystem
permissions. As the manual says, "Note that file permissions will not be stored
in the resulting zipfile.".

You can explicitly list perms using a <zipfileset>.
http://ant.apache.org/manual/CoreTypes/zipfileset.html

Now, is this the problem? That permissions in the file system are not being
picked up and passed to entries in the zip file?
Comment 6 Alexey Solofnenko 2007-04-10 08:02:59 UTC
Maybe it is time to rethink it. R/W attributes are available for some time and
executable permission is in Java 6. Backward compatibility can be affected, so
permission handling should be optional.
Comment 7 Ofir Daniel 2007-04-10 10:19:12 UTC
Steve - your description is right, that is exactly the problem...or WAS the 
problem, since you now showed me that I missed this part in the specs.

I will retry with the <zipfileset>, although I do believe that the 
filesystme's attributes should have been preserved when zipping by default, 
maybe you can consider adding a new parameter to the <zip> task to specify 
this.

FYI - I have tried to zip with winzip and 7-zip, both of these zipped the 
files WITH their original attributes within the filesystem, so why shouldn't 
ANT behave the same?
Comment 8 Jeffrey E. Care 2007-04-10 10:38:32 UTC
Because there's no way to faithfully query the permissions in a pure-Java way?

Take a closer look at the permission-related API additions to java.io.File: I
don't see a way to query ALL of the permission data. The APIs that are there can
only tell you if the current process can read, write or execute a given file -
they don't cover world or groups.

You can _almost_ make an argument for permission preservation for <unzip>, but
even there the APIs don't cover standard UNIX permissions.
Comment 9 Steve Loughran 2007-04-11 02:27:13 UTC
Ok, I've changed the title of the bugrep again,to make it clear its about the RO
bit.

As Jeffrey says, we have been constrained by Java, pre-1.6. Permissions get lost
on <zip>, <tar> and <copy>. More subtly, we are constrained by the need to be
cross platform...you need builds that work on windows as well as unix, so can't
rely on permission bits. Forcing people to use the <zipfileset> permissions does
guarantee that the build file will work on windows, as well as unix.

that said, as alexy notes, the read/read-only flag does appear to be more
portable. File.setReadOnly() is java1.2+ and file.canWrite() is java1.0 era, so
we should be able to propage the writeable flag. For java1.6+, we can even make
a go at execute permissions, though I don't know what happens on Windows in that
situation. Or -and this is the one that scares me- cygwin on windows.

Because of that possibility, I'm leaving this open, instead of WONTFIX/CANTFIX.
We may be able to do something about this, now.