DO NOT REPLY [Bug 1550] - delete task follow symbolic links

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1550>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1550

delete task follow symbolic links





------- Additional Comments From gus.heck@olin.edu  2002-05-02 16:38 -------
So to summarize this bug and propose a general solution:

1. Symlinks on linux can cause annoying, and even potentially dangerous
behavior, particularly with delete and copy type tasks. Understandably users
on these systems might want to write build files that guard against a global
delete of **/*.foo files (such as a accidental symlink to /usr that goes
unnoticed and someone being dumb and forgetting they are su root when doing a
build clean) (*shudder*). (most problems are likely to be much smaller, but
still potentially annoying)

2. Java doesn't understand symlinks very well (at all?), and the mechanisims
for identifying them absolutely in all cases are simply not available.
However, they do fall out nicely on certain file systems comparing absolute
and canonical paths. Our problem is that we don't know what filesystems are
going to be included in a FileSet and there could be more than one.

3. The only person who knows what filesystems are involved is the user who
writes the fileset. (hopefully) Thus the reasonable thing to do is to extend
the functionality that _is_ offered by Java to the user, and let him/her
apply it as needed.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>