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 Sat, 16 Jun 2018 15:59:41 GMT
Den lör 16 juni 2018 kl 17:29 skrev Stefan Bodewig <>:

> On 2018-06-16, Gintautas Grigelionis wrote:
> > 2018-06-16 15:42 GMT+02:00 Stefan Bodewig <>:
> >> On 2018-06-06, Gintautas Grigelionis wrote:
> >>> 2018-06-06 14:31 GMT+02:00 Stefan Bodewig <>:
> >>>> Would the symlink be included in DirectoryScanner's "included files"
> or
> >>>> "included directories"? What will <copy> do to a symlink that
> >>>> 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.
> >> DirectoryScanner's interface provides you with files and directories and
> >> as it stands these File objects may actually by symlinks and the
> >> implicit expectation is that whoever uses them follows the links and in
> >> the end works on the target.
> > If things work as you believe, then it's simple -- FileSets just pass
> > the symlinks to consumers which may or may not check whether File
> > objects are symlinks. In the former case, they might use the new
> > semantics, in the latter case nothing's changed.
> In that case - the later - the followsymlinks="false" and
> skipsymlinks="false" would behave the same as followsymlinks="true" for
> those who do not check whether a file is a symlink, correct?


In case of followsymlinks="false" and skipsymlinks="false" I expect
FileSets or
DirSets to contain symlinks as such; but well-behaved symlink-unaware tasks
would follow the symlinks effectively behaving as if followsymlinks="true"
(the default) with the old semantics.

> >>> I wonder if we can have an interim solution when selectors could use
> >>> proper followsymlinks semantics, but behaviour of DirectoryScanner is
> >>> unchanged?
> >> You may give it a try, I'm not sure exactly what you mean.
> > I attached a test case to one of my previous e-mails to illustrate
> > what I mean.
> The mailing list is configured to not allow attachments.

I just included in my reply on 6/6 at 21.30 without describing what it was
See [1] below.

> One part of it would be symlink support in archives (zip and tar).
> To which extent?
> When creating archives you may need to decide whether you want to use a
> relative or an absolute path to the target (I must admit I have no idea
> whether nio allows us to know how the target has been specified as
> opposed to just what the target is). When extracting and trying to
> re-create symlinks you may also need to watch out for path traversal
> problems.

To the extent where tarfilesets and zipfilesets can make use of symlinks in
the same way as filesets would do.
I am aware of extra complexity with path traversals that may cause loops

What is your time-frame for this? I've been thinking about cutting Ant
> releases soonish, but this is something for a different thread.

This is for the future, I'm quite content with what I could do with
selectors so far
(unless I missed something). I'm looking forward to spend time on symlinks
in other parts of Ant later this summer.



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