f



why no mtime over ftp?

Hello,
not exactly the right group to ask, but full of knowedgeable people anyway.
I'm slowly coming to grips with the fact that the FTP protocol simply
doesn't provide any (portable) means of finding the mtime stamp of the files
on the server. And I mean simple machine-readable timestamps in server OS
resolution, not the impossible-to-regex-invented-on-the-fly garbage 'LIST'
returns.

What I don't understand: WHY? For all practical purposes, the mtime of a
file is just about as important as its name and size, but why didn't the
inventors of FTP ever consider providing a command to retrieve this
information in a consistent form? I know, originally FTP was supposed to be
used in direct human interaction, and LIST is good enough for that. But I
really cannot get my head around the fact that this was never added. Yeah,
I've found RFC3659, but that's from 2007, long after FTP went out of
fashion. I kind of cannot believe that an accurate timestamp wasn't missed
in, say, the first week after FTP's first release. But maybe there is a good
technical reason that I'm not aware of.

Regards,
**Daniel

robert
0
Robert
10/20/2016 9:00:58 AM
comp.unix.programmer 10848 articles. 0 followers. kokososo56 (350) is leader. Post Follow

20 Replies
684 Views

Similar Articles

[PageSpeed] 25

On 20/10/16 20:00, Robert Latest wrote:
> Hello,

> What I don't understand: WHY? For all practical purposes, the mtime of a
> file is just about as important as its name and size, but why didn't the
> inventors of FTP ever consider providing a command to retrieve this
> information in a consistent form?
The original RFC is dated *June 1980*. It would have documented an 
existing technology: so really 70s-era stuff. I doubt many filesystems 
back then would have even had an mtime field.

Presumably you want mtime for automated remote backup/mirroring? Again, 
not sure too much of that in the 1970s: it was cheaper and faster to 
walk to the server and insert the tape.

> I've found RFC3659, but that's from 2007, long after FTP went out of
> fashion.
That's 9 years: how many FTP servers actually running now don't support it?
And in terms of "fashion" it's surprisingly durable. Just recently I
had to use FTP from Python to get files out of a Windows VM: still the 
easiest option, [but if I had to move across the open Internet I would 
use scp.]

AFAICT it's still the standard for entry-level web hosting, ssh/scp
is closely identified with the Unix/Linux tradition and not widely
accepted in the Windows world.

Ian

0
Ian
10/20/2016 9:03:48 PM
On 20 Oct 2016 09:00:58 GMT
Robert Latest <boblatest@yahoo.com> wrote:

> I know, originally FTP was supposed to be used in direct human
> interaction, and LIST is good enough for that.=20

Not "supposed to be".  ftp gives the user a shell for copying files.
It's no accident that LIST usually looks a lot like 'ls -l'.  In the
days of dial-up access and terminal emulation, file transfer wasn't to
be taken for granted.  For comparison, see kermit and xmodem. =20

> But I really cannot get my head around the fact that this was never
> added. Yeah, I've found RFC3659, but that's from 2007, long after FTP
> went out of fashion.=20

The very fact that it *was* added is an indication it didn't go out of
fashion.  It's also a reflection of how ftp is used nowadays: less as
an interactive shell, and more in scripts to automate data delivery and
retrieval. =20

> I kind of cannot believe that an accurate timestamp wasn't missed in,
> say, the first week after FTP's first release.=20

By "accurate timestamp", I think you mean easy to parse.  How do you
get that in an interactive shell today, 36 years after ftp was
standardized?  If not ls (1), maybe stat? =20

[oak]$ stat ~/.emacs
4608 18417710 -rw-rw-r-- 1 jklowden wheel 74197684 5371 "Sep 19
18:43:53 2016" "Apr  3 19:01:27 2015" "Dec  6 19:15:24 2015" "Dec 31
19:00:00 1969" 32768 16 0 /home/jklowden/.emacs

[willow]$ stat ~/.emacs
  File: ?/home/jklowden/.emacs?
  Size: 6050            Blocks: 16         IO Block: 4096   regular file
Device: 801h/2049d      Inode: 8394248     Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/jklowden)   Gid: ( 1000/jklowden)
Access: 2016-10-13 10:36:21.556623419 -0400
Modify: 2016-09-16 10:37:33.002913896 -0400
Change: 2016-09-16 10:37:33.030911108 -0400
 Birth: -

Hmm, or maybe not.  Getting mtime via the shell -- portably -- requires
quite a bit of care, even now.  On the evidence, it's not much missed
in the 1872nd week (more or less).  ;-) =20

--jkl


0
James
10/21/2016 1:14:15 AM
In article <58093124$0$2760$c3e8da3$76491128@news.astraweb.com>,
 Ian Haywood <ian@haywood.id.au> wrote:

> On 20/10/16 20:00, Robert Latest wrote:
> > Hello,
> 
> > What I don't understand: WHY? For all practical purposes, the mtime of a
> > file is just about as important as its name and size, but why didn't the
> > inventors of FTP ever consider providing a command to retrieve this
> > information in a consistent form?
> The original RFC is dated *June 1980*. It would have documented an 
> existing technology: so really 70s-era stuff. I doubt many filesystems 
> back then would have even had an mtime field.

All the operating systems I used in the late 70's had modification times.

But the basic issue was that FTP was designed for interactive use. They 
provided a LIST command that was expected to be analogous to the similar 
command on the target OS, and the user would read the output just as if 
they'd logged into the system.

Probably the reason they provided a STAT command to return the size was 
that this could be used by a RETR command to check that space is 
available before downloading.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
0
Barry
10/21/2016 3:55:19 PM
On Thu, 2016-10-20, Ian Haywood wrote:
> On 20/10/16 20:00, Robert Latest wrote:
>> Hello,
>
>> What I don't understand: WHY? For all practical purposes, the mtime of a
>> file is just about as important as its name and size, but why didn't the
>> inventors of FTP ever consider providing a command to retrieve this
>> information in a consistent form?
> The original RFC is dated *June 1980*. It would have documented an 
> existing technology: so really 70s-era stuff.

I'm too lazy to check, but I think FTP originates in the late 1960s,
even.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .
0
Jorgen
10/21/2016 5:10:10 PM
On 10/21/2016 01:10 PM, Jorgen Grahn wrote:
> On Thu, 2016-10-20, Ian Haywood wrote:
....
>> The original RFC is dated *June 1980*. It would have documented an 
>> existing technology: so really 70s-era stuff.
> 
> I'm too lazy to check, but I think FTP originates in the late 1960s,
> even.

Wikipedia's article on FTP says "The original specification for the File
Transfer Protocol was written by Abhay Bhushan and published as RFC 114
on 16 April 1971."


0
James
10/21/2016 11:06:29 PM
On 2016-10-21, James Kuyper <jameskuyper@verizon.net> wrote:
> On 10/21/2016 01:10 PM, Jorgen Grahn wrote:
>> On Thu, 2016-10-20, Ian Haywood wrote:
> ...
>>> The original RFC is dated *June 1980*. It would have documented an 
>>> existing technology: so really 70s-era stuff.
>> 
>> I'm too lazy to check, but I think FTP originates in the late 1960s,
>> even.
>
> Wikipedia's article on FTP says "The original specification for the File
> Transfer Protocol was written by Abhay Bhushan and published as RFC 114
> on 16 April 1971."

That could just be some relativistic artifact which makes times
before the Epoch singularity appears as times after the Epoch.
0
Kaz
10/22/2016 12:03:49 AM
On Friday October 21 2016 19:06, in comp.unix.programmer, "James Kuyper"
<jameskuyper@verizon.net> wrote:

> On 10/21/2016 01:10 PM, Jorgen Grahn wrote:
>> On Thu, 2016-10-20, Ian Haywood wrote:
> ...
>>> The original RFC is dated *June 1980*. It would have documented an
>>> existing technology: so really 70s-era stuff.
>> 
>> I'm too lazy to check, but I think FTP originates in the late 1960s,
>> even.
> 
> Wikipedia's article on FTP says "The original specification for the File
> Transfer Protocol was written by Abhay Bhushan and published as RFC 114
> on 16 April 1971."
> 


https://www.rfc-editor.org/rfc/rfc114.txt

                        A FILE TRANSFER PROTOCOL

   Computer network usage may be divided into two broad categories --
   direct and indirect.  Direct usage implies that you, the network
   user, are "logged" into a remote host and use it as a local user.
   You interact with the remote system via a terminal (teletypewriter,
   graphics console) or a computer.  Differences in terminal
   characteristics are handled by host system programs, in accordance
   with standard protocols (such as TELNET (RFC 97) for teletypewriter
   communications, NETRJS (RFC 88) for remote job entry).  You, however,
   have to know the different conventions of remote systems, in order to
   use them.

   Indirect usage, by contrast, does not require that you explicitly log
   into a remote system or even know how to "use" the remote system.  An
   intermediate process makes most of the differences in commands and
   conventions invisible to you.  For example, you need only know a
   standard set of network file transfer commands for your local system
   in order to utilize remote file system.  This assumes the existence
   of a network file transfer process at each host cooperating via a
   common protocol.

   Indirect use is not limited to file transfers.  It may include
   execution of programs in remote hosts and the transfer of core
   images.  The extended file transfer protocol would facilitate the
   exchange of programs and data between computers, the use of storage
   and file handling capabilities of other computers (possibly including
   the trillion-bit store data computer), and have programs in remote
   hosts operate on your input and return an output.

   The protocol described herein has been developed for immediate
   implementation on two hosts at MIT, the GE645/Multics and the PDP-
   10/DM/CG-ITS (and possibly Harvard's PDP-10).  An interim version
   with limited capabilities is currently in the debugging stage. [1]
   Since our implementation involves two dissimilar systems (Multics is
   a "service" system, ITS is not) with different file systems (Multics
   provides elaborate access controls, ITS provides none), we feel that
   the file transfer mechanisms proposed are generalizable.  In
   addition, our specification reflects a consideration of other file
   systems on the network.  We conducted a survey [2] of network host
   systems to determine the requirements and capabilities.  This paper
   is a "first cut" at a protocol that will allow users at any host on
   the network to use the file system of every cooperating host.



-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

0
Lew
10/22/2016 1:29:36 AM
James Kuyper <jameskuyper@verizon.net> writes:

> On 10/21/2016 01:10 PM, Jorgen Grahn wrote:
>> On Thu, 2016-10-20, Ian Haywood wrote:
> ...
>>> The original RFC is dated *June 1980*. It would have documented an 
>>> existing technology: so really 70s-era stuff.
>> 
>> I'm too lazy to check, but I think FTP originates in the late 1960s,
>> even.
>
> Wikipedia's article on FTP says "The original specification for the File
> Transfer Protocol was written by Abhay Bhushan and published as RFC 114
> on 16 April 1971."

The *really* late 60s.
0
Joe
10/22/2016 4:03:39 AM
On Sat, 2016-10-22, Joe Pfeiffer wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>
>> On 10/21/2016 01:10 PM, Jorgen Grahn wrote:
>>> On Thu, 2016-10-20, Ian Haywood wrote:
>> ...
>>>> The original RFC is dated *June 1980*. It would have documented an 
>>>> existing technology: so really 70s-era stuff.
>>> 
>>> I'm too lazy to check, but I think FTP originates in the late 1960s,
>>> even.
>>
>> Wikipedia's article on FTP says "The original specification for the File
>> Transfer Protocol was written by Abhay Bhushan and published as RFC 114
>> on 16 April 1971."
>
> The *really* late 60s.

Well, at least it was before punk ...

(And two weeks before my first birthday.)

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .
0
Jorgen
10/22/2016 8:29:36 AM
On 22/10/2016 10:29, Jorgen Grahn wrote:

> (And two weeks before my first birthday.)

(Pet peeve, lost cause)

There is, obviously, only one birth day, unless one is "bourne again" ;-)

And then there are anniversaries ("returning every year").

You may now return to your scheduled broadcast.

Regards.

0
Noob
10/23/2016 8:38:21 AM
Noob , dans le message <nuhstb$9ra$1@dont-email.me>, a �crit�:
>> (And two weeks before my first birthday.)

> There is, obviously, only one birth day, unless one is "bourne again" ;-)

Using space-insensitive languages is hazardous for your mental health.
0
Nicolas
10/23/2016 9:17:23 AM
On 23/10/2016 11:17, Nicolas George wrote:
> Noob , dans le message <nuhstb$9ra$1@dont-email.me>, a �crit :
>>> (And two weeks before my first birthday.)
> 
>> There is, obviously, only one birth day, unless one is "bourne again" ;-)
> 
> Using space-insensitive languages is hazardous for your mental health.

Are you speaking of the propensity of English to form compounds
willy-nilly?

https://en.wikipedia.org/wiki/English_compound
https://en.wiktionary.org/wiki/willy-nilly

Regards.

0
Noob
10/23/2016 4:15:31 PM
Noob , dans le message <nuinmh$bii$1@dont-email.me>, a �crit�:
> Are you speaking of the propensity of English to form compounds
> willy-nilly?

No, I am speaking about the fact that "birthday" is a word all unto itself,
and has meanings that are not exactly the same as the two words "birth" and
"day" side by side.

Breaking news: when you put letters together, they make words and the
meaning change.
0
Nicolas
10/23/2016 4:33:09 PM
On 23/10/2016 18:33, Nicolas George wrote:
> Noob , dans le message <nuinmh$bii$1@dont-email.me>, a �crit :
>> Are you speaking of the propensity of English to form compounds
>> willy-nilly?
> 
> No, I am speaking about the fact that "birthday" is a word all unto itself,

I'm discussing etymology. "Birthday" is obviously derived from
"birth" and "day" (appeared circa late 14th century).

I am lamenting the semantic slide from the logical meaning to
the modern meaning ("birthday anniversary" becomes "birthday").

> and has meanings that are not exactly the same as the two words "birth" and
> "day" side by side.
> 
> Breaking news: when you put letters together, they make words and the
> meaning change.

I don't know about that.

"Football" is a ball that one kicks with the foot.
"Blackboard" is a board that is black.
I could go on literally for hours.

Modern English is very fast to create compounds which have an
obvious (logical) meaning.

Regards.

0
Noob
10/23/2016 7:07:36 PM
Noob , dans le message <nuj1p6$rof$1@dont-email.me>, a �crit�:
> I'm discussing etymology. "Birthday" is obviously derived from
> "birth" and "day" (appeared circa late 14th century).

Do not discuss etymology before learning that it does not give the meaning
of words. No more than knowing your parents would tell us what kind of
person you are.

> I don't know about that.

Indeed.

> "Football" is a ball that one kicks with the foot.

No, "football" is a game where players handle a ball, mostly with their feet
but also with their heads.

(Do not confuse with "armored rugby", the game that Puritanians (the
denizens of the nameless country between Canada and Mexico) call
"football".)

> "Blackboard" is a board that is black.

No, most of them are dark green.

> I could go on literally for hours.

Please do so somewhere else.
0
Nicolas
10/23/2016 7:30:36 PM
On 2016-10-23, Noob <root@127.0.0.1> wrote:
> On 23/10/2016 18:33, Nicolas George wrote:
>> Noob , dans le message <nuinmh$bii$1@dont-email.me>, a écrit :
>>> Are you speaking of the propensity of English to form compounds
>>> willy-nilly?
>> 
>> No, I am speaking about the fact that "birthday" is a word all unto itself,
>
> I'm discussing etymology. "Birthday" is obviously derived from
> "birth" and "day" (appeared circa late 14th century).
>
> I am lamenting the semantic slide from the logical meaning to
> the modern meaning ("birthday anniversary" becomes "birthday").

Your lament is misinformed and laughably dweeby.

"Day" is a suffix word used for all sorts of anniversaries, and this
is a deep rooted historic practice in the language.

As for birthday, etymonline says this:

  birthday (n.)
    late 14c., from Old English byrddæg, "anniversary celebration of
    someone's birth" (at first usually a king or saint); see birth (n.)
    + day. Meaning "day on which one is born" is from 1570s. Birthnight
    is attested from 1620s.

The "day on which one is born" is in fact the new-fangled twist.

>> Breaking news: when you put letters together, they make words and the
>> meaning change.
>
> I don't know about that.
>
> "Football" is a ball that one kicks with the foot.
> "Blackboard" is a board that is black.

No, it isn't. Blackboards are sometimes green. Furthermore,
you cannot call any board which is black "blackboard".
You must call it a "black board". These are *phonetically*
distinct; it's not merely othography:

   black'board    (emphasis on black, "board" unstressed)
   black' board'  (equal emphasis on both)

Example:

"Bob painted the black-and-blue fence white, deliberately leaving only
one {black board | *blackboard}."
0
Kaz
10/23/2016 8:05:45 PM
On 23/10/2016 21:30, Nicolas George wrote:

> Please do so somewhere else.

Perhaps you're right... But I've had it with your attitude.
I'll adjust my filters accordingly to improve my Usenet enjoyment.

0
Noob
10/24/2016 12:17:22 PM
James K. Lowden wrote:
> On 20 Oct 2016 09:00:58 GMT
> Robert Latest <boblatest@yahoo.com> wrote:
>> I kind of cannot believe that an accurate timestamp wasn't missed in,
>> say, the first week after FTP's first release. 
>
> By "accurate timestamp", I think you mean easy to parse.

Not necessarily, but "accurate within server OS granularity" would do it.

> How do you
> get that in an interactive shell today, 36 years after ftp was
> standardized?  If not ls (1), maybe stat? 

I very much dislike ls -l's standard output format, but for interactive use
it's good enough, and for everything else we have stat.

robert
0
Robert
10/24/2016 5:27:02 PM
Ian Haywood wrote:
> Presumably you want mtime for automated remote backup/mirroring? Again, 
> not sure too much of that in the 1970s: it was cheaper and faster to 
> walk to the server and insert the tape.

Indeed I want to use ftp for syncing photos from my 2016 smartphone (which
probably has as much computing power as all 1970s mainframes combined) to a
Linux PC, because nowadays it's cheaper and faster to use WiFi than actually
plugging the phone into the PC and using jmtpfs.

>> I've found RFC3659, but that's from 2007, long after FTP went out of
>> fashion.
> That's 9 years: how many FTP servers actually running now don't support it?

"WiFi File Transfer" doesn't.

robert
0
Robert
10/24/2016 5:31:02 PM
Robert Latest <boblatest@yahoo.com> writes:
>Ian Haywood wrote:
>> Presumably you want mtime for automated remote backup/mirroring? Again, 
>> not sure too much of that in the 1970s: it was cheaper and faster to 
>> walk to the server and insert the tape.
>
>Indeed I want to use ftp for syncing photos from my 2016 smartphone (which
>probably has as much computing power as all 1970s mainframes combined) to a
>Linux PC, because nowadays it's cheaper and faster to use WiFi than actually
>plugging the phone into the PC and using jmtpfs.
>
>>> I've found RFC3659, but that's from 2007, long after FTP went out of
>>> fashion.
>> That's 9 years: how many FTP servers actually running now don't support it?
>
>"WiFi File Transfer" doesn't.
>
>robert

Instead of ftp, why not:

http://android.kowalczuk.eu/rsync4android/

or a similar android rsync client that transports over ssh.
0
scott
10/24/2016 6:30:16 PM
Reply: