Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <42887D46.5000209@javactivity.org>
Date: Mon, 16 May 2005 06:00:22 -0500
From: Steve Cohen <scohen@javactivity.org>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
MIME-Version: 1.0
To: Ant Developers List <dev@ant.apache.org>
Subject: Re: FTP.isUpToDate()
References: <42874D20.9020003@javactivity.org>
 <42885936.9070003@kruithof.xs4all.nl>
In-Reply-To: <42885936.9070003@kruithof.xs4all.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Martijn Kruithof wrote:
> Steve Cohen wrote:
> 
>> In trying to bring over new commons-net timezone functionaility, I 
>> discover the following:
>>
>>    protected boolean isUpToDate(FTPClient ftp, File localFile,
>>                                 String remoteFile)
>>         throws IOException, BuildException {
>> ...
>>        if (this.action == SEND_FILES) {
>>            return remoteTimestamp + timeDiffMillis > localTimestamp;
>>        } else {
>>            return localTimestamp > remoteTimestamp + timeDiffMillis;
>>        }
>>    }
>>
>> Off the top of my head, and given the general logic associated with 
>> the name of the method, can anyone think of a reason why the two 
>> greater-than signs in the above code should not be greater-than-or-equal?
>>
>> In the test case I am developing from the new code, my first iteration 
>> didn't produce the expected results.  I expected one or two files to 
>> be gotten, not the entire directory of 300 files.  When I changed the 
>> >'s above to >='s, the code worked as expected.  Can anyone see 
>> something I'm missing?
> 
> 
> Hi
> 
> Depends on what error is actually wanted. I'd expect
> remoteTimestamp + timeDiff + (remote)granularity > localTimestamp - 
> (local)granularity
> when no risk is to be taken that the file is not copied while it should 
> have been
> or
> remoteTimestamp + timeDiff - (remote)granularity >= localTimestamp + 
> (local)granularity
> when no rist is to be taken that the file is copied while it should not 
> have been.
> 
> When leaving out the granularity I'd say you are right an >= should 
> always be used.
> 
> Martijn
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
> 
> 
> 
I agree with you.  I suppose that with the current code, you can always 
"fudge" the granularities by summing them together as timediffmillis in 
the above code which is a settable parameter.

The case I have in mind is this:

<ftp action = "get"
     ...
     preservelastmodified="true"
     newer="true"/>

Repeating that twice in succession with the current code will ALWAYS 
result in fetching the entire fileset twice whether the source files
change or not.  This seems like an incorrect result, even a bug.

So I want to make this change.

But before I rush off and do that, I want, as a reality check, an idea 
of a use case that this change would break.  I can't think of one.

My thought is that anyone who would want to use this task with 
newer="true" and preservelastmodified="false" isn't going to care about 
granularity-based differences.  That person is simply using the task 
coarsely.  And anyone who would do it as in the above snippet would want 
 >= rather than >.

Please, if someone can come up with a contradictory use case or other 
argument, lay it out here, otherwise I am going to make the change.

The only plausible argument I can think of is backward compatibility of 
existing scripts.  I am guessing that anyone who is trying to use the 
task precisely may already be adding or subtacting 1 in the 
timediffmillis to overcome this problem.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org