https://bz.apache.org/bugzilla/show_bug.cgi?id=70157
Stefan Bodewig <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- OS| |All --- Comment #1 from Stefan Bodewig <[email protected]> --- One could argue we only define what happens when preserveLastModified is true :-) TBH we have always treated this as "if it is true, then ensure the timestamp stays the same, otherwise just don't care for the timestamp at all". We don't ensure the timstamp is changed when a file move succeeds either, I believe. The fail-fast you see for filtering is more of an oversight, now that I think of it. Why would we fall back to copying when moving a directory when the target is a directory as well (the destFile.isDirectory() check just before the filtering check). The whole if expects sourceFile is a real file, I'd say. I can understand you expect the timestamp to change, but <move file="<fileA>" toFile="<fileB>" preserveLastModified="false" /> probably doesn't change the timestamp either as long as you stay on the same filesystem. Again I understand why you expect this - all I say is *I* would not expect thi at all given the attributes description. We can certainly try to ensure the timestamp is changed. We probably should not fail if the move operation passes and the touch operation fails in order to not break builds that have worked fine so far. Of your side node I agree with copyFile and moveFile. renameFile is protected, though, and changing the signature could break subclasses that expect to override it. -- You are receiving this mail because: You are the assignee for the bug.
