ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gintautas Grigelionis <>
Subject Re: [2/2] ant git commit: Bz 22370: followlinks attribute
Date Wed, 06 Jun 2018 19:30:36 GMT
2018-06-06 14:31 GMT+02:00 Stefan Bodewig <>:

> I guess here our API breaks down as we only ever deal with files or
> directories (outside of the symlink task).

FileSet documentation should be more explicit about the matter, in
particular explaining what "followsymlinks" really means.

Would the symlink be included in DirectoryScanner's "included files" or
> "included directories"? What will <copy> do to a symlink that is
> included but not followed.

"Files or directories" dichotomy might be a straitjacket, but symlinks can
be fitted into it depending on what their target is.
Dangling symlinks should go into notFollowedSymlinks.
Regarding <copy>, included but not followed symlink must be left as is (eg
directories are not filtered either).

> The current semantics of fileset's followsymlinks is deeply rooted in
> "we don't know how to deal with links and can only handle files and
> directories". I'm afraid a bunch of tasks will not do what you expect if
> DirectoryScanner suddenly returned File instances that are not real
> files/directories. Either they'd simply follow the link or break down -
> I assume in most cases it will be the former.

True; I wonder if we can have an interim solution when selectors could use
proper followsymlinks semantics,
but behaviour of DirectoryScanner is unchanged?

> > Consequently, I expect
> > followsymlinks="false" skipsymlinks="false" to behave as
> > followsymlinks="false";
> which would be the same as skipsymlinks="true", right?

No, under the new proposal that would include the symlinks as symlinks, not
files or directories.

> > whereas followsymlinks="true" skipsymlinks="true" is ambiguous: if
> > followsymlinks takes precedence, skipsymlinks is redundant; if
> > skipsymlinks takes precedence, then followsymlinks is ignored.
> So we'd need to decide what takes precedence and document it properly.
> As I said above, I don't think Ant's tasks are going to treat
> non-followed symlinks the way you'd expect them to. We could collect
> them separately and add a new getIncludedSymlinks method to
> DirectoryScanner so each task could do what it is supposed to do for
> not-followed links, but then we'll start documenting whether a given
> task X handles those links at all and if so what it does.

That's true; in the meantime, would it make sense to document what
"followsymlinks" means
in FileSet and what "followsymlinks" means in selectors that permit the

There are other issues, like support for symlinks in archives (JRE does not
support them in
zip files [1], rather one -- like Gradle [2] -- must use Commons Compress).
Actually, there are a couple
of old Bugzilla issues addressing symlinks [3, 4] :-).

So, what's the plan?



  <property name="work.dir" value="${}/work"/>
  <delete dir="${work.dir}"/>
  <mkdir dir="${work.dir}"/>
  <touch file="${work.dir}/test.txt"/>
  <symlink link="${work.dir}/link.txt" resource="${work.dir}/test.txt"/>
  <symlink link="${work.dir}/passwd.txt" resource="/etc/passwd"/>

  <property name="" value="${user.dir}/work"/>
  <mkdir dir="${}"/>
  <touch file="${}/test.txt"/>
  <symlink link="${work.dir}/work" resource="${}"/>

  <fileset dir="${work.dir}" id="fileset"/>
  <echo>followsymlinks=true: ${toString:fileset}</echo>
  <fileset dir="${work.dir}" id="fileset-symlinks" followsymlinks="false"/>
  <echo>followsymlinks=false: ${toString:fileset-symlinks}</echo>
  <fileset dir="${work.dir}" id="fileset-is-symlink">
  <echo>symlink followsymlinks=true: ${toString:fileset-is-symlink}</echo>
  <fileset dir="${work.dir}" id="fileset-symlinks-is-symlink"
  <echo>symlink followsymlinks=false:

  <fileset dir="${work.dir}" id="fileset-owned-by-user">
    <ownedby owner="${}"/>
  <echo>ownedby ${}: ${toString:fileset-owned-by-user}</echo>
  <fileset dir="${work.dir}" id="fileset-symlinks-owned-by-user">
    <ownedby owner="${}" followsymlinks="false"/>
  <echo>followsymlinks=false ownedby ${}:

  <property name="" value="wheel"/>
  <fileset dir="${work.dir}" id="fileset-owned-by-group">
    <posixgroup group="${}"/>
  <echo>group ${}: ${toString:fileset-owned-by-group}</echo>
  <fileset dir="${work.dir}" id="fileset-symlinks-owned-by-group">
    <posixgroup group="${}" followsymlinks="false"/>
  <echo>followsymlinks=false group ${}:

  <property name="file.permissions" value="644"/>
  <fileset dir="${work.dir}" id="fileset-with-permissions">
    <posixpermissions permissions="${file.permissions}"/>
  <echo>permissions ${file.permissions}:
  <fileset dir="${work.dir}" id="fileset-symlinks-with-permissions">
    <posixpermissions permissions="${file.permissions}"
  <echo>followsymlinks=false permissions ${file.permissions}:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message