| Summary: | [PATCH] File paths to imported build files should not be canonicalized | ||
|---|---|---|---|
| Product: | Ant | Reporter: | Jesse Glick <jglick> |
| Component: | Core tasks | Assignee: | Ant Notifications List <notifications> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | ||
| Priority: | P3 | ||
| Version: | 1.6.0 | ||
| Target Milestone: | 1.6.2 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Attachments: |
Suggested patch (modified files)
ZIP of added files for the test case |
||
Created attachment 11294 [details]
Suggested patch (modified files)
Created attachment 11295 [details]
ZIP of added files for the test case
Hi Jesse,
The reason I used canonicalpath here was because the imported file
may import other files. One could set up something like this.
/a/scripts/overall.xml
/a/scripts/b/import.xml
containing <import file="../overall.xml"/>
and one could set a symbolic link to /a/scripts/b, say /usr/home/peter/b_scripts
a build-file could then contain:
<import file="/usr/home/peter/b_scripts/import.xml"/>
which would work with the canonical path, but not with the AbsolutePath
In such a case you could make the symlink to /a/scripts, not /a/scripts/b, and <import file="/usr/home/peter/a_scripts/b/import.xml"/> Clearly in this case /a/scripts is intended to be a whole (you cannot use the b subdir on its own), so linking to just a part of it sounds dubious to me. I realize that there are cases where having the canonical path would be handy, but is it worth the (possibly unsolvable) problems for those people who *don't* want the canonical path? Other Ant tasks (in particular, <property>) don't magically traverse symlinks or otherwise canonicalize file paths. Maybe better to have an explicit task to canonicalize a file path and store the result in a new property, if that's really what you want. Or perhaps an extra attribute 'canonicalize' on <import> (default should be false, IMHO). BTW import.html in the manual still states "Important: We have not finalized how relative file references will be resolved in deep/complex build hierarchies -such as what happens when an imported file imports another file. Use absolute references for enhanced build file stability, especially in the imported files." Ok applied the patch and updated the manual entry for the import task Cheers, Peter Re. <subant>: cf. bug #30438, fixed for 1.6.3. |
If you import a build script fragment via a path that at runtime follows a Unixish symlink, Ant will define ${ant.file.whatever} to be the canonicalized (physical) path, rather than the logical path. If you were using this property to define other paths, as is common, then your set of path definitions can be "poisoned" by the physical path components. An example of this problem can be found in the netbeans.org build system, which recently began using <import> with Ant 1.6.0; this caused a regression whereby it was no longer possible to build the source tree in case some modules were stored in a symlink farm, because the imported script paths would refer to the physical location and further computed paths might no longer be inside the symlink farm area. A messy workaround for common cases was found; details: http://www.netbeans.org/issues/show_bug.cgi?id=40892 Generally using File.getCanonicalPath/File except at user request is a bad idea, as it can break build setups using symlinks. Historically, Ant 1.4 fixed this problem, so the behavior in 1.6.0 is sort of a regression (only if you use <import> of course): ---%<--- Date: 2001/07/10 16:39:47 Author: bodewig Log: Stop using canonical paths. This will change the behavior of Ant when symbolic links are present (but in a way that is probably closer to what the user expects) and remove some problems on platforms that use "uncommon" native file names like OS/390 or VMS. Submitted by: Jesse Glick <Jesse.Glick@netbeans.com> WHATSNEW:1.121->1.122 src/main/org/apache/tools/ant/Project.java:1.62->1.63 src/main/org/apache/tools/ant/ProjectHelper.java:1.52->1.53 ---%<--- Also cf. http://marc.theaimsgroup.com/?l=ant-dev&m=99358037323340&w=2 The attached patch corrects the problem for <import>. It seems <subant> still uses File.getCanonical*, probably incorrectly; I have no patch for that yet. Includes an additional unit test which (if run on Unix) confirms that the imported file path is the logical, not physical, path. If there was some purpose to canonicalizing the file path in ImportTask.java, I am not aware of it (no apparent comments or unit tests explaining it).