Stefan Bodewig wrote
> > There is a small problem :
> >
> > <ftp action="get"
> > server="${ftp.host}"
> > userid="${ftp.user}"
> > password="${ftp.password}"
> > remotedir="${tmp.dir}">
> > <fileset dir="foo/bar" includes="**/*.java" />
> > </ftp>
> >
> > used not to follow symbolic links (in ant 1.5.3 and before)
>
> symlinks on the remote side?
>
> > now, it will follow symbolic links because the default for filesets
> > is to follow symbolic links.
> >
> > Is this OK
>
> Not sure.
>
> > the only possibility I see is to add a flag in AbstractFileSet to
> > find out whether followsymlinks has been *** explicitly *** set.
> > Makes the code fatter but would maintain compatibility of behavior
> > between ant 1.5.3 and ant 1.6
>
> An alternative (although a hacky one) invoke setFollowSymlinks with
> false in FTP#addFileset(). As it is addXYZ and not addConfiguredXYZ
> any explicitly set attribute would override it (as the attributes will
> get set after the invocation of add). Hmm, wait, you only want to
> change the followsymlinks attribute if the fileset is a remote one,
> right? You probably don't know that by the time addFileset gets
> invoked.
>
yes, the followsymlinks problem concerns the cases where the fileset is
remote, so all actions other than put.
> > Or can we say that the non following of symbolic links by the ftp
> > task was a bug,
>
> +0, I'm not really sure and I don't really know what the expected
> behavior would be. I'd probably expect put and get to behave the same
> way, so the 1.5.x behavior would be wrong.
>
I am going to write in WHATSNEW under the section "changes that can break
existing environments" :
<ftp> task : followsymlinks="false" in nested fileset definitions is
explicitly required in order to exclude symbolic links.
Cheers,
Antoine
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
