Re: FTP.isUpToDate()

[Steve Cohen]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]