ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <br...@callenish.com>
Subject Re: Bug 49261 - <copy> and Read-Only Destination Files
Date Mon, 10 May 2010 19:06:12 GMT
On 10/05/2010 8:27 AM, Stefan Bodewig wrote:
>
> you won't like what I'm going to say 8-)
>    

Oh man, it is never easy, is it?

> The following non-deprecated tasks use copyFile or copyResource as well:
> <move>, the WebLogic deployment tool,<netrexxc>,<rmic>.<concat>
 and
> <echo>.
>
> For most of them I'd be willing to accept the backwards incompatibility
> and just have the tasks throw exceptions if they cannot write to the
> destination files.  The main exception to me would be<move>  and
> <concat>.
>    

I agree. These are the ones we need to be cautious about. Possibly echo 
could be an issue as well, but is less of a concern I think, so long as 
it gets a force flag (or equivalent).

> <move>  will try to perform a rename which falls back to delete if
> File#rename fails - so in general it will replace read-only files.  To
> be consitent it should either check whether the destination is read-only
> before trying to rename as well, or it should always overwrite existing
> files in copy mode.  I tend to perform the check before renaming and am
> not sure what the default should be.
>    

I think the check before renaming makes sense.

As for the default, I'm still torn. I think that our current behaviour 
is just a bit obnoxious: I don't care how you've marked permissions on 
your files, I'm going to do what I want. But thinking of all the builds 
that might be blithely relying on that behaviour is a bit scary. So 
again, leaning toward force=false

> <concat>  already defines an attribute named force - and it does just
> what the attibute named overwrite does for<copy>.  Does anybody have a
> good idea for an attribute name that says "overwrite read-only
> destination files" and can be used in both<copy>  and<concat>?
>    

What a pain. But given enough time we can fix this:

     1) On Concat, add an overwrite attribute and mark the force 
attribute as deprecated with a warning
     2) Add force to copy, echo, etc
     3) add forceReadOnly to Concat

Eventually we can get to the point where we remove force crom Concat 
altogether for a release or two, and then reintroduce it.

Is it worth the effort to get this consistency, or have I slipped into 
the land of Hobgoblins for little minds?


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message