Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!olivey!jerry
From: jerry@olivey.olivetti.com (Jerry Aguirre)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: FTP "STRU VMS" extension
Message-ID: <38267@oliveb.olivetti.com>
Date: 23 Feb 89 00:59:21 GMT
References: <8902082217.AA08143@pinocchio.UUCP> <603089521.0.KASHTAN@IU.AI.SRI.COM>
Sender: news@oliveb.olivetti.com
Reply-To: jerry@olivey.UUCP (Jerry Aguirre)
Organization: Olivetti ATC; Cupertino, Ca
Lines: 28

In article <603089521.0.KASHTAN@IU.AI.SRI.COM> KASHTAN@IU.AI.SRI.COM (David L. Kashtan) writes:
>>If it's a matter of saving steps why not just build a DCL wrapper
>>which does the job? Heck, Interlisp-D had what amounted to a very good
>>NFS based on vanilla FTP, required no changes to the server (eg. UNIX
>>or VMS) system as I remember.
>  This is a solution -- though not a pretty one.  It loses on several
>  fronts:
>	1) It doesn't address the issues of system management and disk
>	   quotas.   It is definitely not a selling point for the software
>	   if you are required to have 2 times the disk space available
>	   in order to transparently transfer the files

I think there is a basic misunderstanding here brought about by the
different philosophy of Unix and VMS users.  The VMS users are assuming
that they "backup" or whatever into a file, transfer the file, extract
the files, and then cleanup the temporary files used to store the backup
image.  Thus the requirement for the extra space for the backup.  (Don't
they have the equivelent of a /tmp directory?)

A Unix user implementing the same facility would assume that the data
was being "piped" directly from the output of "tar" to the ftp transfer.
No temporary file names or disk space would be needed and also no long
delay creating the backup before the transfer can start.  And of course
the ftp output can also be piped into tar on the receiving end to
achieve the same benifits.

The common usage of pipes in Unix and the ability of tar and dump to use
them make this an unspoken assumption.