Addendum to Martin Bøgelund's answer:
The why-question (which I assume is "why did the original attempt do what it did") is interesting, and simple when you think about it the right way: it's the same
dir [remote-directory] [local-file] syntax, where the remote directory happens to be
>. The ftp client is not a shell. Commands typed into it are not shell commands. It doesn't have redirection operators, and
> is not a special character.
Yes, you can have a directory named
> on your FTP server, as long as you aren't running it on Windows.
ftp.exe found in Windows is a copy of an early BSD ftp. It doesn't know about Windows filename restrictions. If you tell it to
get remotefile > it will try to save a copy of the remote file as a local file called
>, and fail because of the local filesystem limitations.
A major contributor to the confusion here is that the FTP server, receiving a
LIST command with
> as the argument, responded with a success code and an empty reply body instead of saying "No such file".