Quoting Dominique Devienne <[EMAIL PROTECTED]>:
> > From: Jacob Kjome [mailto:[EMAIL PROTECTED] > > > > I have noticed that the <copy> and <move> tasks update the file > timestamp > > even > > if overwrite="false", making it somewhat hard to determine whether it > is > > only > > touching the file or actually ignoring the overwrite="false". > > Do you know about preservelastmodified? (it defaults to false). --DD >
Ug! Thanks Dominique. Yes, I missed that but, in my defense, I've never had to
think about it for any cases where I've used <copy> or <move> until now. Sorry
for the noise.
Hold on, looks like I spoke too quickly. I added preservelastmodified="true" to my <move>. I tried this with both overwrite="false" and excluding said attribute. The file's modified date continues to be updated to the current date/time. Am I missing something else or is this a bug?
Note that the commons-vfs <v-copy> and <v-move> tags seem to behave properly here, and also have what I consider to be more intuitive defaults (overwrite defaults to "false" and preservelastmodified defaults to "true"). Not only that, but the <v-copy> and <v-move> are totally consistent in their behavior where Ant's <copy> task has overwrite defaulting to "false" and <move> has it defaulting to "true".
Now, I would just use <v-copy> and <v-move> all the time except for the fact that my build bootstraps itself, downloading commons-vfs, and can't use it until it has it locally, so there are certain parts of the build which require <copy> and <move> to work properly.
So, can someone verify whether this is a real bug or whether I just picked the wrong day to stop sniffing glue (anyone catch that reference?).
Thanks,
Jake
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
