This is a minor feature request for usability. Summary: when using the copy task and overwrite is false (or none is set, defaulting to false) and verbose is true, and it decides not to overwrite, copy should print that it's not overwriting the files because they exist. Currently, in 1.6.5, copy doesn't print anything in this case. This is a usability issue, for a couple reasons. Imagine the following task: <copy file="a" todir="folder/" verbose="true"/> After execution, the user sees no output, gets confused because usually copy gives output in verbose mode when it copies or fails. Next, the user checks the file time -- and the file time still says yesterday. The user really gets confused, maybe thinking this is a bug. If the user is used to the unix "cp" command, the default is to overwrite without asking, not caring whether the files are the same or not, so the default behavior of copy might be unintuitive to users unfamiliar with the "overwrite" flag. The simple fix is to have copy print something in this case, such as "File ___ not overwritten because source file has not been updated" in verbose mode when overwrite is false. My reason: In my experience, this has happened twice (several years apart) and each time it took me quite a few hours to track down the functionality of copy and figure out why it wasn't happening -- should have been obvious if I'd looked in the right places, but it wasn't. There might be a separate issue that I haven't tracked down yet. On my setup when overwrite is false (by default) it's not overwriting even though the source files have a newer modification date. (I'm using Linux, Fedora Core 3, ant 1.6.5 in Eclipse). This is a separate issue that I haven't tracked down yet but may be a separate entry if I find an actual bug there.
There should already be such a verbose warning being issued by the code that checks files for up-to-date-ness. But if your files are not being overwritten anyway, I would think that issue would be the thing to scrutinize.