Summary: | tar task looses file permissions | ||
---|---|---|---|
Product: | Ant | Reporter: | Eric Haszlakiewicz <erh+apache> |
Component: | Core tasks | Assignee: | Ant Notifications List <notifications> |
Status: | NEW --- | ||
Severity: | enhancement | ||
Priority: | P2 | ||
Version: | 1.7.1 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Linux |
Description
Eric Haszlakiewicz
2009-10-26 14:54:41 UTC
There are many facets to this and I'll sure miss some: * tar supports non-File resources as well, which do not provide said information at all * canRead and friends will give you information about the current user, is that the owner, a group member or "other"? * canExecute is Java6 and beyond, Ant's svn trunk targets Java 1.4. For a long time Java's file API has simply been insufficient and was the reason Ant didn't even try to deduce permissions - and it still mostly is, in particular when you take Ant's conservative compatibility requirements into account. * canExecute most likely returns false for directories (haven't tried) and canRead/Write likely show something different from Unix permissions for directories as well - so we'd need special handling for dirs. * checking the permissions for all files is likely a time-consuming operation, java.io.File isn't exactly known for its efficient implementation. Initially Ant didn't support storing permissions at all and when it started to do so, it only was with the help of tarfileset/zipfileset. The documentation doesn't say you won't get proper permissions directly, but it could be derived from the paragraph starting with "In addition to the implicit fileset" - but this may be a stretch. svn revision 830262 improves the situation a bit. |