Bug 28505 - [PATCH] File paths to imported build files should not be canonicalized
Summary: [PATCH] File paths to imported build files should not be canonicalized
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.6.0
Hardware: PC Linux
: P3 major with 1 vote (vote)
Target Milestone: 1.6.2
Assignee: Ant Notifications List
Depends on:
Reported: 2004-04-20 20:58 UTC by Jesse Glick
Modified: 2008-02-22 12:18 UTC (History)
0 users

Suggested patch (modified files) (2.74 KB, patch)
2004-04-20 20:58 UTC, Jesse Glick
Details | Diff
ZIP of added files for the test case (1.56 KB, application/octet-stream)
2004-04-20 20:59 UTC, Jesse Glick

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2004-04-20 20:58:09 UTC
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:


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
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>


Also cf.


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).
Comment 1 Jesse Glick 2004-04-20 20:58:56 UTC
Created attachment 11294 [details]
Suggested patch (modified files)
Comment 2 Jesse Glick 2004-04-20 20:59:55 UTC
Created attachment 11295 [details]
ZIP of added files for the test case
Comment 3 peter reilly 2004-04-26 10:21:23 UTC
Hi Jesse,
The reason I used canonicalpath here was because the imported file
may import other files. One could set up something like this.

       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
Comment 4 Jesse Glick 2004-04-26 19:45:53 UTC
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."
Comment 5 peter reilly 2004-04-29 12:05:33 UTC
Ok applied the patch and updated the manual
entry for the import task
Comment 6 Jesse Glick 2004-12-02 20:46:48 UTC
Re. <subant>: cf. bug #30438, fixed for 1.6.3.