commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neeme Praks <>
Subject Re: [net] FTPclient: keeping track of dates of files on the server
Date Thu, 24 Mar 2005 10:04:49 GMT
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 :-)


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:
> For additional commands, e-mail:

View raw message