Re: Ant 1.5 Beta1 Sneak Preview ready - DirScanner patch

["Patrick (Gus) Heck" <pa...@olin.edu>]

So I read through bug 1550 delete follows symlinks. It does look like my
patch could be used to fix this. Given the discussion there, and the definite
morass of possibilities of filesystems, the way to look at things seems (to
me) to be this:

---

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.

---

So what I propose is to modify my current patch so rather than setting a
followLinks attribute, we set a isCanonical atribute. This can the be
propogated up to FileSet/MatchingTask and the documentation can mention it's
utility in avoiding symlinks, and mention the difficulties in using it across
samba or on case insensitive filesystems.

Sound good?

Gus

Stefan Bodewig wrote:

> On Thu, 2 May 2002, Magesh Umasankar <um...@apache.org> wrote:
>
> > would it mean changing a bunch of files?
>
> DirectoryScanner and FileSet - maybe MatchingTask.
>
> It would add a new optional followsymlinks attributes that defaulted
> to true, thus preserving the old behavior.  It is rather unlikely to
> break anything.  But then again, I've been the one who just said
> "let's not add new functionality between betas" ten mails ago 8-)
>
> Stefan
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>


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