On Wednesday, March 8, 2017 3:43:46 AM CET Mike Frysinger wrote:
> On 08 Mar 2017 08:38, Josef Moellers wrote:
> > On 07.03.2017 21:51, Mike Frysinger wrote:
> > > On 07 Mar 2017 16:14, Josef Moellers wrote:
> > >> When a colleague checked timestamps handling in vsftpd, he found that
> > >> wget is expecting that timestamps received from ftp server have the
> > >> same
> > >> timezone as the client.
> > >>
> > >> in src/ftp-ls.c:ftp_parse_unix_ls()
> > >> It reads time of modification from directory listing (.listing) which
> > >> should be in UTC according to
> > >> https://tools.ietf.org/html/rfc3659#section-3.1 and creates timestamp
> > >> using mktime(timestruct) which honors local timezone configuration.
> > >> This
> > >> breaks timestamps.
> > >
> > > i don't see any of timezone (utc or otherwise) in that document.
> > > iiuc, the time stamps are not standardized across OS's or server
> > > implementations, so wget can't take a hard line either: it isn't
> > > possible to always return the right answer.
> >
> > Well ... The referenced section (which I should have read prior to
> > forwarding this report) references a "time-val" and in section 2.3 of
> > said document it explicitly states that
> >
> > "Time values are always represented in UTC (GMT), and in the Gregorian
> > calendar regardless of what calendar may have been in use at the date
> > and time indicated at the location of the server-PI."
> >
> > So: yes, you're right, the referenced section does not specify a time
> > zone, but the RFC in general does.
>
> back up. that RFC is not "the entire file transfer protocol", it is
> specifically a subset. from its intro:
>This document updates the File Transfer Protocol (FTP) [3]. Four new
>commands are added: "SIZE", "MDTM", "MLST", and "MLSD". The existing
>command "REST" is modified. Of those, the "SIZE" and "MDTM"
>commands, and the modifications to "REST" have been in wide use for
>many years. The others are new.
>
> that means it does not cover the LIST command which is what your initial
> report is about.
>
> further, it also says:
> https://tools.ietf.org/html/rfc3659#section-2.3
>The syntax of a time value is:
> time-val = 14DIGIT [ "." 1*DIGIT ]
>
> i don't know if i've ever seen an ftp server use that format for dir
> listings. so making wget follow it wouldn't really help.
>
> here's the RFC you probably want to refer to:
> https://tools.ietf.org/html/rfc959#page-32
> LIST (LIST)
>
> This command causes a list to be sent from the server to the
> passive DTP. If the pathname specifies a directory or other
> group of files, the server should transfer a list of files
> in the specified directory. If the pathname specifies a
> file then the server should send current information on the
> file. A null argument implies the user's current working or
> default directory. The data transfer is over the data
> connection in type ASCII or type EBCDIC. (The user must
> ensure that the TYPE is appropriately ASCII or EBCDIC).
> Since the information on a file may vary widely from system
> to system, this information may be hard to use automatically
> in a program, but may be quite useful to a human user.
>
> pay specific attention to the last sentence.
>
> random spot check of oftpd, pure-ftpd, and vsftp show the same behavior:
> -rw-r--r-- 1 001903 Mar 8 00:40 ddnuke.c
> -rw-r--r-- 1 21 21422 Mar 30 2014 Makefile
>
> that's a UNIX format, and it's not possible to even reasonably guess
> as to the timezone let alone full timestamp. that's EST btw, not UTC.
>
> a cursory search of MS IIS behavior says they support UNIX or DOS
> directory listing formats. i've seen VMS ones too.
Thanks for all the details, Mike.
Just want to add that someone put much effort into detecting and parsing the
different types of listings (see ftp-ls.c). That is Unix, Windows, VMS, MacOS
(like Unix). All is local server time.
> there's nothing reasonable wget can do here.
For VMS listings there is
" VMS normally provides local (server) time and date information.
Define the logical name or environment variable
"WGET_TIMEZONE_DIFFERENTIAL" (seconds) to adjust the receiving local
times if different from the remote local times."
If someone needs that for other kinds of listings, I wouldn't reject a patch.
Tim
signature.asc
Description: This is a digitally signed message part.
