This takes the advice from
http://files.stairways.com/other/ftp-list-specs-info.txt
further: search for the date by an explicit occurrence of a known month
name. This means that we won't see files with bad names (they'd be
filtered out of the result), but the filtered out entries are ones that
would not be usable with `ftp-make-file-seconds'.
When the month is found, and the entry is a file, look for a number
preceding the month, and if found, return it as the file size string.
This is a minor change in the API. (But it's probably better to either
revise it further, or eventually make it irrelevant by exposing the
interesting functionality via `net/url'.)
This function was using 2002 when there's no year... Updated it to use
the last occurrence of the guessed date, as described at
http://files.stairways.com/other/ftp-list-specs-info.txt
This function still looks pretty bogus -- the RFC does *not* say
anything about the format of response to `LIST', so it's whatever
semi-random thing the server does. (The above link looks like an
attempt to fix it, but I didn't see anything more official than that.)
From some looking around, it looks like ftp clients just try a bunch of
patterns against the text. Add also warnings in the documentation about
this.
RFC 2640 specifies that all transport strings are assumed UTF-8 if they
can be parsed as such. To make this complete it should really send a
FEAT and check that the result has "UTF8", but it's kind of redundant
since there's not much else to do if it isn't.
Also, switch to a more correct line endings of CRLF when sending
messages to the server.
