Bug 39544 - <copy verbose="true" overwrite="false">
Summary: <copy verbose="true" overwrite="false">
Status: NEW
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.6.5
Hardware: PC Linux
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Ant Notifications List
Depends on:
Reported: 2006-05-10 14:36 UTC by Aaron Powers
Modified: 2008-11-24 03:58 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Powers 2006-05-10 14:36:06 UTC
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.
Comment 1 Matt Benson 2006-05-10 15:20:23 UTC
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.