https://issues.apache.org/bugzilla/show_bug.cgi?id=47821
Johan Corveleyn <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | --- Comment #2 from Johan Corveleyn <[email protected]> 2009-09-14 04:43:18 PDT --- I understand this is difficult to do, and cannot be done without using platform-specific Runtime.exec code. It's a pity that the Java api doesn't offer you a way to do this. But isn't there a way you could do the following, in the touch task, when no datetime argument is given? * Try setLastModified(System.currentTimeMillis()) * If that fails (i.e. returns false), and the platform is unix, try a Runtime.exec of touch? At the very least, touch should raise an error when it fails to set the timestamp. File.setLastModified returns a boolean to indicate whether or not it succeeded. This return value is currently ignored. Can you use that return value to raise an error if needed? Maybe this could also be documented in the manual for the touch task? Some background: in our build environment, this issue has caused serious problems after we switched from Linux to Solaris, and it was hard to find out what exactly went wrong. We used the copy task to deploy a new build to a JavaWebStart server. By default, the copy task only copies newer files, if they already exist on the target location. Because the touch failed, sometimes old files (which needed to be redeployed) were not copied. It took us quite some time to figure out why it failed, and to replace all touch tasks with <exec ... />. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
