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. Too bad change of Java ownership left things unfinished, as in archive support. > >> 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. > We could add new array of symlinks that are not supposed to be followed > but most tasks would simply ignore them (all tasks that we don't change > ourselves). > > > Dangling symlinks should go into notFollowedSymlinks. Regarding > > <copy>, included but not followed symlink must be left as is (eg > > directories are not filtered either). > > Probably. There will not be a interpretation that will work for all > tasks, it will be on a task by task basis. As we can only control the > tasks that are inside of Ant's codebase, this means we must not change > the interpretation of the files and directories returned by > DirectoryScanner at all. > That is fine as long the tasks follow symlinks in a FileSet and no additional structures for keeping them is needed. If there are tasks that might choke on/skip a File which is a symlink, or, as is the case with shared libraries on U*X, add multiple copies of the same file to an archive by following symlinks, then there's more work to do. > > 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. > >>> Consequently, I expect > >>> followsymlinks="false" skipsymlinks="false" to behave as > >>> followsymlinks="false"; > > >> which would be the same as skipsymlinks="true", right? > > > No, under the new proposal that would include the symlinks as symlinks, > not > > files or directories. > > Where would DirectoryScanner put those included symlinks? > Either treat them as files/directories, or put in a separate structure, as discussed above. > in the meantime, would it make sense to document what "followsymlinks" > > means in FileSet and what "followsymlinks" means in selectors that > > permit the attribute? > > We must document that, I'd say :-) > That's done. > > There are other issues, like support for symlinks in archives (JRE does > not > > support them in > > zip files [1], rather one -- like Gradle [2] -- must use Commons > Compress). > > Actually, there are a couple > > of old Bugzilla issues addressing symlinks [3, 4] :-). > > I know Commons Compress pretty well ;-) and it doesn't really support > symlinks in archives either. Given that Ant's zip package is the parent > of Compress' zip support we should be able to do whatever Commons > Compress can do here as well. There is a good reason why we don't use > java.util.zip at all. > 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. > > 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). Another part would be investigating of what DirectoryScanner could do and what is expected of FileSet/DirSet, then deciding whether it is possible to fit the symlinks in there. Gintas
