Re: [2/2] ant git commit: Bz 22370: followlinks attribute
Den lör 16 juni 2018 kl 17:29 skrev Stefan Bodewig <bodewig@xxxxxxxxxx>:
> On 2018-06-16, Gintautas Grigelionis wrote:
> > 2018-06-16 15:42 GMT+02:00 Stefan Bodewig <bodewig@xxxxxxxxxx>:
> >> On 2018-06-06, Gintautas Grigelionis wrote:
> >>> 2018-06-06 14:31 GMT+02:00 Stefan Bodewig <bodewig@xxxxxxxxxx>:
> >>>> Would the symlink be included in DirectoryScanner's "included files"
> >>>> "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.
> >> 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
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  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
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.