When using the replace task file permissions such as user execute are not presserved. This is probably because the task creates a temp file and renames it once the replaces have been completed(guessing have not read the code). What needs to happen is that some sort of a stat() should be called before modifying the file and the permissions should be reset to what the stat() returned earlier. Not sure how to do a stat() from Java, so I am submitting as a defect.
Sadly, this is really a CANTFIX, rather than a wontfix. As you yourself said, "Not sure how to do a stat() from Java" There is no easy way to do it; one was promised for Java1.4 but it didnt make the cut, we cant use JNI without shipping a library for every platform ant runs on, etc. Unless something can be done calling an external app, the way we get environment variables on many platforms, we are all going to have to wait for Java1.5. The same problem arises with <copy>, so everyone is aware of it. sorry.
In the short run, copying file and directory permissions could be accomplished by creating a <copypermissions> task which extends/emulates the <copy> task but which would only copy file permissions. As this seems to be more of an issue with UNIX OS's and Perl tends to be widely available, a Perl script could be invoked for that instance of the task which would receive via its stdin a paired list of source and destination files or directories. For each line it reads in, it would do a stat() on the source file and set the corresponding permissions on the destination file. After the list of files, the task would close its output stream to Perl causing the script to exit. Since this Perl script would be invoked only once for the task instance rather than on a per file basis, performance should be very good.