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>: >>>> 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. >> You are right. In a Java world where you couldn't really do anything >> with symlinks it has probably been clear implicitly. > I would argue that things are less clear implicitly since Java 7, we just > seemed to ignore it. Right. >>>> 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? >>> 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. > Hmm, I've got an impression that Commons Compress was more capable; > if Ant can handle zip and tar files with symlinks, then a big part of the > job is done. Commons Compress and Ant are the same in that you can create an archive that contains entries that look like symlinks to tools that know how to handle them. And at least in the case of tar and Commons Compress they will tell you a certain entry is a symlink (for zip you need to detect that yourself by looking at the flags). In that sense we can create archives with symlinks in them and we will be able to detect an entry inisde of an archive is a symlink. I'd have to check whether we need to backport anything from Commons Compress in order to make the little symlink support that is there is also available to Ant. >>> So, what's the plan? >> It's your itch, what is your plan? :-) > 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. What is your time-frame for this? I've been thinking about cutting Ant releases soonish, but this is soemthing for a different threat. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
