Return-Path: 
 <ant-user-return-10086-apmail-jakarta-ant-user-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-user-archive@jakarta.apache.org
Received: (qmail 62830 invoked by uid 500); 12 Jul 2001 12:00:06 -0000
Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:ant-user@jakarta.apache.org>
List-Help: <mailto:ant-user-help@jakarta.apache.org>
List-Unsubscribe: <mailto:ant-user-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:ant-user-subscribe@jakarta.apache.org>
Reply-To: ant-user@jakarta.apache.org
Delivered-To: mailing list ant-user@jakarta.apache.org
Received: (qmail 61216 invoked from network); 12 Jul 2001 11:58:39 -0000
Message-ID: <20010712115839.43581.qmail@web9706.mail.yahoo.com>
Date: Thu, 12 Jul 2001 04:58:39 -0700 (PDT)
From: Don Taylor <donald_l_taylor_jr@yahoo.com>
Subject: Re: uptodate task not setting property properly
To: ant-user@jakarta.apache.org
In-Reply-To: <20010711175043.37149.qmail@web9707.mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

I'll answer my own question with what I know so far. The problem
appears to be with the JRE. Here's what I know:

1. The timestamp of the file on the server, retrieved using
File.lastModified(), is '994769776896'

2. The timestamp of the local file (on Windows 95) is '994769776000'

3. The timestamp of the local file (on Windows NT) is '994769776896'

Because of this discrepancy, the uptodate task thinks the file on the
client is out of date on a Windows 95 machine. As part of my process
after I determine the file is out of date I copy the file to the client
using the preservelastmodified attribute. That forces a call to
File.lastModified() on the source and taking the return value as the
argument to File.setLastModified() on the destination.

I wrote a little Java program that then repeats these steps:

1. Call File.setLastModified(994769776896L);
2. Call File.lastModified() store result in lmNew and compare.

On a Windows 95 machine lmNew is '994769776000'. Amazingly enough on my
Linux (Mandrake 8.0) machine I got the same results as with Windows 95!
But my NT box will always set lmNew to '994769776896'

Check out a comment made by rlcannonjr in the Bug Parade on bug ID
4137636. He's reporting the same behavior on an SGI system.


--- Don Taylor <donald_l_taylor_jr@yahoo.com> wrote:
> Hi all. Here's a task I'm executing:
> 
> <target name="checkForUpdates" if="server.update.available">
>   <uptodate property="updates.notAvailable">
>     <mapper type="glob" from="*" to="${parentdir}/*"/>
>     <srcfiles dir="${server.update}"/>
>   </uptodate>
> </target>
> 
> What I'm trying to do is contact a server, ${server.update}, and
> compare the set of files found there to the set of local files. There
> is a one-to-one correspondence between the files.
> 
> Here's the deal: this works great on my machine (a Windows NT 4.0 SP6
> box running Java 1.3.0-C). If I delete a local file,
> ${updates.notAvailable} is not defined, or if a local file is
> out-of-date it is not defined. Perfect.
> 
> The problem is on a client's machine running Windows 95 and also
> running Java 1.3.0-C. Of the couple dozen or so files that are
> checked,
> a couple of them *always* say they're out of data. I've used the
> verbose option to see what's going on, and all you see is that the
> file
> was added because the local file was outdated. Of course if you look
> at
> the file dates and times in explorer on both the client and the
> server
> they are identical. Like I said, according to the log the task found
> the *majority* of the files up to date, only a couple is it having
> problems with.
> 
> I did check the source and found that ultimately the uptodate task
> relies on SourceFileScanner.restrict(String[], File, File,
> FileNameMapper) to do the heavy work. This method will ultimately
> create a source and dest File object and then compare the results of
> their File.lastModified() methods. I *did* check the Bug Parade to
> see
> if there were any applicable issues with this method. I didn't find
> anything.
> 
> So does anyone have any ideas?
> 
> Thanks.
> 
> 
> =====
> Don
> 
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail
> http://personal.mail.yahoo.com/


=====
Don

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/