ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Bug 49261 - <copy> and Read-Only Destination Files
Date Fri, 07 May 2010 14:52:01 GMT
Hi all,

it seems we have a difference in behavior between FileChannel and
FileOutputStream that manifests itself in <copy>.

When using streams - i.e. Ant prior to 1.8.0 or when filtering - Ant
will happiliy overwrite read-only destination files if the source file
is newer.  When using channels it will throw an exception (Access

First of all I must admit that I like the idea of not overwriting
read-only files better than the old behavior.

Independent of that we should make sure <copy> behaves consistently, it
shouldn't matter whether there are filters or not.

We can certainly get the old behavior back into the NIO branch by
deleting any existing dest file first - if we can't do that, then we are
out of luck, I guess.  We could fall back to the stream code in that

I see several options:

(1) make the NIO code behave like the stream code and always overwrite
    read-only files if the source is newer (or the overwrite attribute
    has been set).

    Basically - recreate the Ant behavior pre-1.8.0.

(2) Add a new attribute that controls whether read-only files should be
    overwritten (let's rely on File.canWrite).

    What should be its default value?  What would be its name?

(3) Make the existing overwrite atribute control whether read-only files
    will be replaced.

Personally I prefer (2) and wouldn't want to overwrite read-only files
by default.  overwrite would be a wonderful name for the attribute but I
don't want to combine the "even if the destination is more current"
logic into it.  Hmm, force like in "cp -f"?

What do you prefer?


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

View raw message