commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Cohen <sco...@javactivity.org>
Subject Re: [net] FTPclient: keeping track of dates of files on the server
Date Thu, 24 Mar 2005 12:25:17 GMT
Sorry I didn't read far enough.

This is more properly a discussion for the Ant list.  All we handle here 
is the raw FTP.  Ant's FTP task depends on commons-net, though, and 
until we release the timezone-using version of commons-net, ant will not 
have the tools to do what you need.

I may be speaking out of turn here, but I doubt that that Ant developers 
will be receptive to your suggestion.  The ant <ftp> task has been 
designed as a fairly simple wrapper around raw <ftp>.  The "newer" 
attribute of the <ftp> task offers just a simple date-time comparison 
within the general dependency framework of ant.

It sounds like what you are asking for is something much more, basically 
a version-control system.  Ant supports several of these and my guess is 
that they will tell you to use cvs or one of the proprietary version 
control systems that ant supports in order to accomplish this logic. 
Have you considered using the <cvs> task of ant?  I programmed one of 
the version-control systems that ant supports and your issues sound very 
familiar to me.

But I could be wrong, also.  If you outline your use case on the ant 
list, you may find more interest in supporting it than I expect.  If you 
do, I suspect that would be implemented in a new task that perhaps sits 
on top of <ftp>, because there are still many use cases for using the 
<ftp> task as is.

In any case, the timezone feature of commons-net-ftp will be part of any 
possible solution.

Neeme Praks wrote:
> Well, as I wrote in my previous email, timezone setting does help, but I 
> would like to take it one step further.
> When just using plain timezone difference calculation, you are still 
> comparing server time to the local time and those usually are out-of-sync.
> I would like to have it 100% precise: to compare server time to the 
> server time and local time to local time.
> If you would read my original post again, maybe you would see the light :-)
> 
> Rgds,
> Neeme
> 
> P.S. It's a "Mr", as usual in technology mailing lists. Nice try, though 
> :-P
> 
> Steve Cohen wrote:
> 
>> Spot on again, Mr. (Ms.?) Praks.  And again, the latest version of CVS 
>> allows the specification of a server time zone, for precisely this 
>> reason.
>>
>> We need to get this released and then supported in Ant.
>>
>> Steve Cohen
>>
>> Neeme Praks wrote:
>>
>>> Hi again!
>>>
>>> Another issue I've been thinking about.
>>> Correct me if I'm wrong but the current way that FTP client checks if 
>>> the file locally is newer or not is the following:
>>> 1. it takes the time from the server
>>> 2. manipulates the time according to timezone settings
>>> 3. compares it to the time on the local file
>>>
>>> In the ideal case, when the local machine time and the server time 
>>> are in sync, this scheme should work.
>>> However, we do not live in the ideal world. So usually the local time 
>>> and the server time does not match.
>>> This results in four scenarios, and here is my ASCII art illustration:
>>> "lf" = "local file"
>>>                   |    lf IS UPDATED       |    lf IS NOT UPDATED
>>> -------------------+------------------------+---------------------------
>>> timestamp shows lf | this is BAD, changes   | this is OK, as there is
>>> as OLDER than the  | stay on local disk     | no update required
>>> file on the server | nothing is uploaded    | anyway
>>> ------------------ +------------------------+---------------------------
>>> timestamp shows lf | this is OK, as the     | this is not really bad but
>>> as NEWER than the  | file has to be updated | NOT GOOD either. we will
>>> file on the server | anyway                 | constantly try to update
>>>                   |                        | files that are already
>>>                   |                        | up-to-date
>>> -------------------+------------------------+---------------------------
>>> Actually there is one more axis to this: if the file on the server is 
>>> updated or not. But it is very similar to the case above, so I will 
>>> not go into details of that issue now.
>>>
>>> Hopefully that made sense?
>>> I would like to avoid these undesirable scenarios.
>>> How to do that?
>>> By comparing apples to apples and oranges to oranges: by comparing 
>>> the server timestamp to the timestamp from the same server and local 
>>> timestamp to local time.
>>> In order to do this, we just need to keep a list of timestamps around 
>>> somewhere, from session to session.
>>>
>>> My proposal:
>>> When FTP client does checks for timestamps, it stores the last known 
>>> server and local timestamps of each file in some designated "working 
>>> directory".
>>> And after each upload, it updates those timestamps. Then, it can 
>>> easily determine, if the file on the server has been overwritten or 
>>> if the local file has been updated since the last synchronization.
>>> If the local file is unchanged and server file is unchanged - skip.
>>> If the local file is changed and server file is unchanged - upload.
>>> If the local file is unchanged and server file is changed - skip. Or, 
>>> optional behaviour could be to download changes.
>>> If the local file is changed and server file is changed - upload and 
>>> issue warning. Or, the default behaviour could be to just issue warning.
>>> And we could implement synchronizing file deletions also.
>>>
>>> The directory contents could look something like this:
>>>    commons-net-ftp-timestamp-cache/my-ftpserver.cache - one file per 
>>> unique server
>>> inside that file would be something like this:
>>> [file path] [server timestamp] [local timestamp]
>>> [file path] [server timestamp] [local timestamp]
>>> [file path] [server timestamp] [local timestamp]
>>> ...
>>> [file path] [server timestamp] [local timestamp]
>>>
>>> What do you make of all this?
>>> Does it make any sense?
>>>
>>> I would be willing to work on implementing this unless someone has 
>>> some better ideas for achieving similar results.
>>> Should this actually go inside commons-net or maybe inside the Ant 
>>> task instead?
>>>
>>> Rgds,
>>> Neeme
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>>


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


Mime
View raw message