Subject: Ftp-WG: Re: minor example error in draft-ietf-ftpext-mlst-10

From: David Borman <[email-masked]>
Date: Tue, 13 Jun 2000 09:08:56 -0500

> Date: Tue, 13 Jun 2000 08:22:12 -0500
> From: Robert Elz <[email-masked]>
> To: FTPEXT Working Group <[email-masked]>
> Subject: Ftp-WG: Re: minor example error in draft-ietf-ftpext-mlst-10
...
> Aside from restart (which is what the SIZE command was invented for)
> I have yet to see a plausible excuse for knowing the exact transfer size
> of a file ... being able to stick in wacky HTTP headers by http->ftp gateway
> type things (why do they exist anyway, browsers do ftp?) seems to me to be
> no rationale at all.

Ok, I'll offer up another reasonable use of the SIZE command.

At Cray Research, the file system under Unicos provided the ability to
pre-allocate files.  This had the advantage of allowing you to make sure
you had enough free disk space for large files before starting the
transfer, and it sped the actual writes to the file system, since all
the data blocks were pre-allocated.  So, before doing a GET, we'd issue
a SIZE command and use that info for file pre-allocation.

(And if I recall correctly, for small files the data was stored
in the inode itself.  Once you crossed the threshold, a data block
was allocated and the data in the inode was copied out to the block.
Doing a pre-allocation eliminated that extra copy, with the initial
data going directly into the data block.)

		-David Borman, [email-masked]

---

From: Robert Elz <[email-masked]>
Date: Tue, 13 Jun 2000 09:22:54 -0500

Date:        Tue, 13 Jun 2000 09:08:56 -0500
    From:        David Borman <[email-masked]>
    Message-ID:  <[email-masked]>

  | Ok, I'll offer up another reasonable use of the SIZE command.

For that, is the precise transfer size needed, or just a pretty good idea
of roughly how big the file is going to be?

In fact, unless the storage encodings were identical to transfer encodings
for all transfer types, all SIZE would be giving you is an approximation to
the storage size in any case.

I can understand making use of SIZE to do that, when the alternative was
attempting to parse the output from LIST, but it seems to be overkill to
me, assuming some other way of obtaining a good size estimate is available.

kre