RE: and update timestamp even if overwrite="false"

[Jacob Kjome]

Ok, I've got the behavior figured out.  If the source file is newer than 
the destination file, then <move> seems to overwrite the destination, even 
if overwrite="false".  I guess this only applies when the destination file 
is newer.  A re-read of the docs pointed this out to me, but I don't find 
it all that intuitive.  And, even though the docs are clear on this, I had 
it in my head that preservelastmodified referred to the preserving the 
destination file's last modified date, but what it really does is preserve 
the source file's last modified date.

Ok, while I still think behavior of the commons-vfs <v-copy> and <v-move> 
tasks are more intuitive, I now understand that Ant's <copy> and <move> 
tasks are working as designed and, therefore, there is no bug.

Again, sorry for the noise.
Jake
At 02:31 PM 7/31/2004 -0500, you wrote:
At 10:49 PM 7/30/2004 +0000, you wrote:
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]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]