ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: Potential breaking change to symlink task [ was Re: Jenkins build became unstable: Ant-Build-Matrix-master-Linux » JDK 1.8 (latest) #977]
Date Sun, 10 Dec 2017 11:45:57 GMT
[@Steve I'm trying to drag you in as you've been the one who brought in
the change that gets contested by and maybe you
recall the details better than we do.]

On 2017-12-10, Jaikiran Pai wrote:

> On 10/12/17 3:09 PM, Stefan Bodewig wrote:
>> On 2017-12-10, Jaikiran Pai wrote:

>>> I'll investigate why this is failing (local tests pass for me) and fix it.

>> Target testCreateOverFile in the antunit test explicitly tries to
>> replace a file with a link, doing exactly what the bugzilla report says
>> is a bug. So the behavior seems to have been intentional.

>> We now need to figure out whether the bug report was genuine (and list
>> the change as breaking) or we want to revert part of your fix, change
>> the documentation and change the bugzilla issue's resolution to a

> The symlink task documentation[1] states this for the "overwrite" attribute:

> <quote>
> Overwrite existing links or not.
> </quote>

> It does explicitly mention that it's meant for overwriting links. The
> test here, like you note, tries to overwrite a non-symlink file and
> IMO it should error out, like it does with this change. After all, the
> entire symlink task is meant to just deal with symlinks and
> overwriting non-symlinks doesn't seem right. Having said that, I do
> agree that this is a change in behaviour and we should list this as
> such, if we do decide to let this change stay.

> The reason why that existing test was introduced in first place and
> the feature to let the symlink task overwrite a non-symlink file goes
> back to this issue
> The rationale in
> that description seems to be that the Unix ln -sf apparently allows
> overwriting non-symlink file with a symlink. Given that context, I'm
> not really sure how we should proceed. Should we make this breaking
> change or should we let the prior behaviour continue?

> I'm in favour of this breaking change, but I won't mind switching back
> to the prior behaviour if you and others think that's a better thing
> to do.

Thank you for digging into the history, Jaikiran.

43426 is explicitly listed as a fixed bug (in 1.8.0) so I'm leaning
towards keeping and documenting the behavior of allowing <symlink> to
replace regular files.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message