Very Computer

I am trying to develop an ftp mechanism that will only transfer files
from a remote host which were created after the latest timestamp from
files transferred in the previous ftp operation.

The problem I am wonderng about is that the remote server may crash
and come back up with a "different" system date/time which could
result in some files not being ftp'd.

Can anybody suggest a solution to this or is there some "standard"
solution to this problem?

Thnaks

Phil

Network time protocol (NTP).  http://www.ntp.org

rsync is a very convenient way of handling this.
http://rsync.samba.org

Quote:> The problem I am wonderng about is that the remote server may crash
> and come back up with a "different" system date/time which could
> result in some files not being ftp'd.

The solution for this is to keep its clock correct.  NTP is usually
used for this purpose.  http://www.ntp.org

--

Nate Eldredge

: I am trying to develop an ftp mechanism that will only transfer files
: from a remote host which were created after the latest timestamp from
: files transferred in the previous ftp operation.
:
: The problem I am wonderng about is that the remote server may crash
: and come back up with a "different" system date/time which could
: result in some files not being ftp'd.
:
: Can anybody suggest a solution to this or is there some "standard"
: solution to this problem?
:
Here is a new FTP client that does exactly what you describe:

  http://www.columbia.edu/kermit/ftpclient.html

Use the UPDATE option, described here:

  http://www.columbia.edu/kermit/ckermit3.html#x3

Also see the sample scripts here:

  http://www.columbia.edu/kermit/ftpscript.html

- Frank

Most commonly accepted solutions to this general problem assume correct time
being in use on all of the involved machines.  This isn't the case in this
situation, so I doubt they (any of the commonly accepted solutions) will
work.

Quote:>> The problem I am wonderng about is that the remote server may crash
>> and come back up with a "different" system date/time which could
>> result in some files not being ftp'd.

>The solution for this is to keep its clock correct.  NTP is usually
>used for this purpose.  http://www.ntp.org

Again, by assumption, I think it is to be assumed that having the remote
machine on proper time is not an option.  If it were, any of the standard,
commonly accepted solutions would work, and the OP probably would have just
used one of them instead of posting to the Usenet.

As it is, the problem is an interesting and intriguing one - I'm not sure
off hand what the solution is.

Couldn't you ue ntp to figure out what time the remote machine _thinks_
it is, then use some local calculations to get what you want?

Richard

: >



: > >
: > >> I am trying to develop an ftp mechanism that will only transfer files
: > >> from a remote host which were created after the latest timestamp from
: > >> files transferred in the previous ftp operation.
: > >
: > ...
: > Most commonly accepted solutions to this general problem assume correct
: > time being in use on all of the involved machines.  This isn't the case in
: > this situation, so I doubt they (any of the commonly accepted solutions)
: > will work.
: > ...
: > >The solution for this is to keep its clock correct.  NTP is usually
: > >used for this purpose.  http://www.ntp.org
:
: Couldn't you ue ntp to figure out what time the remote machine _thinks_
: it is, then use some local calculations to get what you want?
:
Again: The new Kermit ftp client:

  http://www.columbia.edu/kermit/ftpclient.html

takes care of all this for you.  A detailed description of the precise
mechanism for update mode when uploading is given here:

  http://www.columbia.edu/kermit/ckermit3.html#x3.5.2

It also applies to downloading, but in the reverse direction.  Bear in mind
that the server reports a file's time in GMT (UTC), but you don't know what
time zone the server is in.  When downloading, you can have Kermit give the
downloaded file the current time, or the time from the server -- your choice
(in UNIX, which uses GMT/UTC internally anyway, this is just what you want).
If you use the latter method, e.g.:

  get /update *

then only the files that are newer than those already downloaded will be
downloaded again.

- Frank