https://bz.apache.org/bugzilla/show_bug.cgi?id=19252
--- Comment #5 from Stefan Bodewig <bode...@apache.org> --- well, what I said nineteen years ago is no longer true as of Java 7 (about eleven years ago) - which means Ant 1.10.x may be able to create symbolic links by now (Ant 1.9.x still lives in a Java 5 compatible world). The meat of what <untar> does lives in Expand#extractFile: https://github.com/apache/ant/blob/62a464710e666e5972fa2775a097e80ca217c9ee/src/main/org/apache/tools/ant/taskdefs/Expand.java#L254 which is shared by untar and unzip and doesn't even know the entry of the tar archive in detail. It would be possible to implement the symlink logic in Untar by not invoking extractFile if the tar file is a symbolic link. I don't think it is very complex to do so I'll list a few things to consider that just occur to me: * we probably want an explicit task attribute that must be activated to enable the creation of symlinks. The current behavior of not creating symlinks but rather plain files may be expected by existing users. * we need something similar to untar's allowFilesToEscapeDest for symlinks that point outside of the directory tree - and default to prohibit external symlinks IMHO. Most likely we will want to think about the interaction of symlinks and stripAbsolutePathSpec as well. I see potential for reuse of some logic that currently sits in extractFile here * we need to define what happens if the target file system doesn't support symlinks at all or symlink creation fails for other reasons. Do we just fail the build or do we create a file like the task would do without any changes - or do we need yet another flag to control the behavior? Apart from that it "just" takes somebody to actually find the time and write the code ;-) -- You are receiving this mail because: You are the assignee for the bug.
