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