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
WONTFIX.
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 https://bz.apache.org/bugzilla/show_bug.cgi?id=43426. 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.
[1] https://ant.apache.org/manual/Tasks/symlink.html
-Jaikiran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
