ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Glick <>
Subject [PATCH] Avoid canonicalization of symlinks
Date Tue, 26 Jun 2001 18:35:03 GMT
I have some memory of a similar thread coming up on the list before but 
don't remember any particular resolution.

The attached patch avoids any use of File.getCanonicalPath() within the 
Ant core. In current sources, any file names encountered are 
canonicalized quite aggressively, which on Unix means symlinks are followed.

Why do I think this is bad? Symlink farms are broken by this "feature". 
Consider a situation like this (which has bitten me):

common/build.xml: <ant dir="../a"/> <ant dir="../b"/> ...
a/build.xml: ...
b/build.xml: ...

Pretend a/ and b/ are both major code modules, and common/ some 
infrastructure to build them both. Now imagine you want to work on a CVS 
branch of a/ while keeping the public trunk of b/. You might try this:

mkdir ~/testing
cd ~/testing
cvs co -rtestbranch a
ln -s ~/trunksrc/b b
ln -s ~/trunksrc/common common
ant -f common/build.xml

You expect this to build stuff in ~/testing/b/ == ~/trunksrc/b/, which 
it does, and ~/testing/a/, which it does *not*: it uses ~/trunksrc/a/ 
(hopefully you notice!). Is this intuitive for anyone?

The reason is that the canonicalization of the file right away tells Ant 
that the build script it is starting with is 
/home/me/trunksrc/common/build.xml, and "../a" relative to that is 

The patch simply disables canonicalization while continuing to use 
absolute paths, so that Ant will think of 
/home/me/testing/common/build.xml as its starting point, and never 
explicitly know about /home/me/trunksrc/ at all. In other words, the 
symlink farm you set up is honored by Ant. (It also makes the code a bit 

Surely someone will have a counterexample where they *do* want symlinks 
followed (I'm not quite sure why but could imagine it). Wouldn't this 
more safely be done at explicit user request? E.g.:

<property name="maybe-symlinked" location="../other-project"/>
<!-- Hypothetical new task: -->
<canonicalize property="other-proj-dir" location="${maybe-symlinked}"/>
<!-- Task which is not symlink-safe (caches?): -->
<dosomethingwith file="${other-proj-dir}/foo"/>

Also consider build logs in a big Unix shared-disk system:

ant -f /sources/build.xml all
[javac] Compiling 2 files to /sources/java
[javac] Compiling 2 files to /mnt/dsk0013/projects/foo/sources/java

There may be value in leaving canonicalization on in as it 
could prevent duplicates differing only in symlink path. I have no idea 
if this happens commonly, or if it is really a problem when it does.

Other pluses/minuses?


Jesse Glick   <>
NetBeans, Open APIs  <>
tel (+4202) 3300-9161 Sun Micro x49161 Praha CR

View raw message