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 00:48:39 GMT
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


Mime
View raw message