Den lör 16 juni 2018 kl 17:29 skrev Stefan Bodewig <bode...@apache.org>:
> On 2018-06-16, Gintautas Grigelionis wrote: > > > 2018-06-16 15:42 GMT+02:00 Stefan Bodewig <bode...@apache.org>: > > >> On 2018-06-06, Gintautas Grigelionis wrote: > > >>> 2018-06-06 14:31 GMT+02:00 Stefan Bodewig <bode...@apache.org>: > > >>>> 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. > > >> 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? > 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 etc. 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. Gintas [1] http://marc.info/?l=ant-dev&m=152833304425275&w=2
