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 Mon, 04 Jun 2018 22:02:27 GMT
2018-06-04 8:26 GMT+02:00 Stefan Bodewig <>:

> What happens when I do something like this
> <fileset dir="..." followsymlinks="false">
>   <ownedby owner="me" followsymlinks="true"/>
> </fileset>
> I believe - but haven't tested it - that for symlinks <ownedby> is never
> going to be invoked at all as DirectoryScanner will skip the symlink so
> the attribute's value on ownedby is irrelevant. If I'm correct we should
> probably document it somewhere.
> Of course the same is true for the existing <symlink> selector, so this
> is a more general task.

Stefan is right -- "followsymlinks" for the fileset should have been called
"skipsymlinks" or something like that.

What's worse, the way things are now, there is a risk for confusion.
I'd like add "skipsymlinks" and change "followsymlinks" for the fileset so
a fileset behaves as follows:

none of the attributes set (default):

skipsymlinks=false, followsymlinks=true (for consistency -- breaks BWC);

one ore both attributes set:

followsymlinks=true, skipsymlinks not set => warn, followsymlinks=false and
skipsymlinks=false for BWC;
followsymlinks=false, skipsymlinks not set => warn and skipsymlinks=true
for BWC;

skipsymlinks=false, followsymlinks set => new semantics for followsymlinks;
skipsymlinks=false, followsymlinks not set => new semantics,
followsymlinks=true for consistency;
skipsymlinks=true => followsymlinks not set -- ditto, else a warning about
useless attribute?

What do you think?


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