UTC happens to be the right choice more often than any other time zone, and will be even more often in future, since newer internet drafts explicitly specify the use of UTC.
You might want to try the --mdtm option introduced in version 0.3.10
if this really, really bothers you. But be warned, --mdtm throws
away performance. See the manual page for more information.
Depending on the quality of implementation the API doesn't even work
reliable.
Some of the most often used and unfortunately badly implemented
FTP servers change the format of their time stamps after a few
months (most often 6). They then "forget" to print hours and
minute information, like in this example:
In any case this problem will vanish as soons as servers start to
provide the "MLST" command.
The --mdtm option provides a workaround, but see
above. Another workaround is to not get files
more than 5 months old, after ftpcopy has run the first time.
Besides: There ain't something "for free". Everything has a
price, including my time.
There are a number of workarounds which all doesn't work in every
case.
Note that i, as the author of every single GPLd file in this
package, have the right to do this. Please don't bother to question
that.
See also the
GPL and
mixedcopyright
entries in my general FAQ.
If ftpcopy does not compile under your Unixoid then please feel free
to report this bug, or better still: feel free to send a patch.
ftpcopy works around this, so you can ignore this warning message.
But note that to get rid of this annoying warning you have to contact
the FTP servers administrator and / or the FTP servers software maintainer.
On the bright side: ftpcopy does an atomical replacement of files on the
local machine.
Q1.1 Why isn't there an option for the servers time zone?
Answer:
Reasons include:
There's a reason for this: The C API for
dealing with time zones is so horrible that nobody likes to touch it.
It's safe to assume that the inventors have been killed by annoyed
programmers or life hidden in some place there they are hard to find.
They shouldn't be allowed to do more inventions anyway.
Besides that it's slow. Really slow.
This can happen with other options too, of course, but these options
are at least useful, if not needed. And they don't ruin the code.
1.2 Why does ftpcopy re-get a file after an half year? [obsolete]
Answer:
Note: This problem has been solved in version 0.5.1. The information
below is left for users of older versions.
drwxr-xr-x 4 root wheel 1024 Aug 1 2000 file1
drwxr-xr-x 2 root wheel 2048 Dec 23 06:40 file2
The net effect is that ftpcopy assumes 00 hours and 00 minutes.
2.0 Why can't ftpcopy work the other way round?
I want a way to create a mirror on an FTP server and cannot
run ftpcopy there. Can't you add this functionality to ftpcopy?
Answer:
Short answer: no.
Long answer: The program ftpcopy isn't designed to be the latest
and greatest all-round FTP client, but explicitly does _one_ thing.
It may seem easy to add the "other way round" functions, but it
isn't.
2.1 Just add an abstraction layer and you get this for free!
Answer:
I thought about that, but i don't think this will work. There are
many, many differences between a local file system and an FTP server.
And the abstraction layer would most possible have a very heavy
influence on the code.
2.2 Why isn't there an upload tool?
Answer:
Reasons include:
Both workarounds fail if the server doesn't tell the time stamps for
freshly created files.
3.0 What copyright does ftpcopy have?
Answer:
The package is published under the GNU General Public License, Version 2.
Some files are published under a different license. See the file
"LICENSE" in the source distribution for a list.
A files license has a higher precedence than the package license.
Any conflict arising from the different licenses is to be resolved
on that base.
3.1 Why isn't every file GPLd?
Answer:
One reason is the included DNS library. It's just "the right thing".
I like API, features, securities and stability. I don't like the
copyright, but i can live with it: distribution of patches or
unmodified files is allowed.
3.2 Why don't you use a BSD license?
Answer:
This entry has been moved.
4.0 What systems does ftpcopy run on?
Answer:
ftpcopy should compile under reasonable UNIX systems and lookalikes.
This includes, but is not limited to, Open/Free/NetBSD and Linux.
"Reasonable" includes an ANSI C compiler.
4.1 Are binary packages available?
This entry has been moved.
4.2 What to do with specifications for .rpm, .deb, .pkg and so on?
or
... I've written a [binary package specification]. Here's it!
This entry has been moved.
4.3 Does ftpcopy work with socks?
Answer:
ftpcopy from version 0.3.8 on will work with the runsocks program
from the socks5 reference implementation if you use the --force-select
option and have a directly reachable DNS resolver.
4.4 "temporarily unable to figure out IP address" during self check
Or, in full length:
ftpcopy: fatal: temporarily unable to figure out IP address for nonexistinghost:ftp: temporary failure
Answer:
Most probably your /etc/resolv.conf is misconfigured and one or all of the
DNS servers in it or one or all of the DNS servers for one of the domains
in the "search" or "domain" list do not provide an answer.
4.5 What does 'malformed MLSx listing' mean?
Answer:
This means that the FTP server sent an malformed answer. According to
draft-ietf-ftpext-mlst-14.txt (7.2, 7.4) each and every, including the
very last, fact in a listing has to be terminated by a semi-colon (;).
Quite a number of FTP server authors obviously misunderstood this.4.6 Does ftpcopy need special make commands?
Answer:
The makefile should be quite portable now (as of version 0.4.9), though
i cannot be sure, since i can't test ftpcopy with every system on this
world. ftpcopy, as of 0.4.9, has been make with dmake, pmake and gmake.
Earlier versions were known to not compile with the HP-UX make.
5.0 How does ftpcopy deal with files still being uploaded?
Or
how would ftpcopy deal with a file that is being
uploaded to the server ftpcopy will be downloading from.
Answer:
It depends on the server. ftpcopy can't tell that a file is being
uploaded (and/or incomplete), but the FTP server _could_ hide a file
being uploaded, or could replace it atomically after the upload
is completed, by using a hidden temporary file.
It's very likely that, in the real world, the answer is a simple "you lose".