Subject: ON THE FLIGHT COMPRESSION

From: "EDI" <[email-masked]>
Date: Thu, 6 Feb 1997 10:54:20 -0200

I didn't understant how the "on the flight compression" feature works. Can
anybody help me, please? I´ve put compress, tar and gzip commands in the
ftp
tree and configured the ftpconversions and ftpaccess files. Nevertheless, I
couldn't manage to make the compression work. :-(

---

From: "EDI" <[email-masked]>
Date: Thu, 6 Feb 1997 14:37:48 -0200

About the questions below, the compression is not working at all. I am
working with Solaris 2.4 on a Spark 1000 server. About PATH, gzip, compress
and tar are in the same directory ( ~ftp/usr/bin, linked to /bin) as ls,
wich is working fine. I am not sure about how starting the transfer with
compression. Would it be transfering, for exemple, TEST file as TEST.Z?
----------
From: George Ross <[email-masked]>
To: [email-masked]
Subject: Re: ON THE FLIGHT COMPRESSION 
Date: Thursday, February 06, 1997 1:55 PM

> "On the Flight Compression" occurs when you order tickets on certain
> carriers who use special "dynamic compression payload adjusters" that
> slowly squish packets into tiny little balls during long international
> hops. By compressing the passeng.. uh, packets, greater throughput is
> obtained on the long haul internation routes. Some carriers claim they
> can fit twice as many packets into the same space!

Perhaps RFC 1149 is relevant here too.

As regards the "on the fly" compression that the original poster was
wondering 
about, did it work for "real" users and not for anonymous ones, or did it
just 
not work at all?  If the former then I would suspect that something that
the 
utilities depend on is missing from the chroot()ed tree.  If the latter
then 
perhaps the daemon's PATH might be relevant.

It would also be useful to know what kind of system is being used, as there

may be some particular quirk which someone on the list might know about.

In any case, if there's some way to trace the daemon's execution as it
fails 
to do the compression, then that might give some useful hints as to the 
problem.

-- 
Dr George D M Ross, Department of Computer Science, University of Edinburgh
       Kings Buildings, Mayfield Road, Edinburgh, Scotland, EH9 3JZ
Mail: [email-masked]   Voice: +44 131 650 5147   Fax: +44 131 667 7209
   PGP: 1024/B74A4F7D  14 E8 B3 00 20 04 68 F8  95 40 CB 36 A4 D4 FA 90

---

From: Will Brown <[email-masked]>
Date: Thu, 6 Feb 1997 18:08:06 -0500 (EST)

> From: "EDI" <[email-masked]>
> To: <[email-masked]>, <[email-masked]>

That would be a Sparc 1000 I presume. And I'm jealous.

First, this feature of wu-ftpd only works for downloads. You
absolutely cannot upload a compressed tar file and expect the server
to know that it is supposed to uncompress and untar it (as much as we
might like such a feature, it can't be done without changing the FTP
protocol).

Furthermore, while you can do on-the-fly tar or zip of directories,
the reverse doesn't make sense in this context. eg: download archive.tar.gz
and expect it to be automatically expanded on the server and sent to you
file by file. Sorry, but again you'd have to change the FTP protocol
and probably the client software.

ie: this is a server feature that relies upon NO changes to the FTP
protocol, and no special features on the client side.

Now, The server receives a request to download TEST.Z. If that file
exists, then fine, it sends it to you. If not, but a file named TEST
exists then the server compresses TEST on the fly, and you get TEST.Z
as though it had existed on the server. But if a directory named TEST
exists, no go, unless you request TEST.tar or TEST.tar.Z or
TEST.tar.gz or maybe even TEST.zip - in which case you get on-the-fly
archiving possibly combined with compression.

OTOH, suppose that TEST.Z exists (but not TEST), and you request TEST.
The server obliges and sends you TEST by uncompressing TEST.Z and
sending you the result. This might be handy if you were on a peecee
and didn't have uncompress available.

Now, for all of this to work for anonymous users, you need statically
compiled binaries for compress and tar and gzip and maybe even zip (as
in PK).  (or dynamic binaries, and all the required libraries in
~ftp/usr/lib.).

It is also necessary to have the FTP server configured properly.

You need lines such as these, in the ftpaccess file:

compress        yes             local remote
tar             yes             local

These are EXAMPLES only! See ftpaccess(5) for details.

You also need an ftpconversions file with specifications of what conversions
are allowed. Here is one possible ftpconversions file that supports
on-the-fly compress, decompress, gzip, gunzip, tar, tar and compress,
tar and gzip, and PK-like zip.

 :   : :.Z:/bin/compress -c %s:T_REG:O_COMPRESS:COMPRESS
 :.Z:  :  :/bin/compress -cd %s:T_REG|T_ASCII:O_UNCOMPRESS:UNCOMPRESS
 :   : :.gz:/bin/gzip -c %s:T_REG:O_COMPRESS:GZIP
 :.gz: :  :/bin/gzip -cd %s:T_REG|T_ASCII:O_UNCOMPRESS:GUNZIP
 :   : :.tar:/bin/tar -c -f - %s:T_REG|T_DIR:O_TAR:TAR
 :   : :.tar.Z:/bin/tar -c -Z -f - %s:T_REG|T_DIR:O_COMPRESS|O_TAR:TAR+COMPRESS
 :   : :.tar.gz:/bin/tar -c -z -f - %s:T_REG|T_DIR:O_COMPRESS|O_TAR:TAR+GZIP
 :   : :.zip:/bin/zip -qr - %s:T_REG|T_DIR:O_COMPRESS|O_TAR:ZIP

at least, it seems to work for me under Solaris 2.4 and 2.5, alas not
on a 1000, but on 5's and 10's. Doing zip is definitely questionable,
but I think I tested it once :)

--
Will Brown
sorry, no .sig