Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!julius.cs.uiuc.edu!apple!agate!shelby!portia.stanford.edu!draphsor
From: draphsor@portia.Stanford.EDU (Matt Rollefson)
Newsgroups: comp.sys.mac.misc
Subject: Re: Compactor
Message-ID: <1990Sep21.213106.20332@portia.Stanford.EDU>
Date: 21 Sep 90 21:31:06 GMT
References: <1521@camex.COM> <1990Sep10.205758.7075@silvlis.com> <1530@camex.COM>
Organization: AIR, Stanford University
Lines: 30

In article <1530@camex.COM> kent@camex.com (Kent Borg) writes:
>Compactor is being too smart.  I want a dumber way to do it.  What if
>the "output archive media" is a uucp mailer that barfs on files that
>are too big?  Does one need to create a set of SilverLining partitions
>of mailer-limit size?

The problem here is that what you want to do is segment a file (it could
be any file, not necessarily a compactor file) for transmission.  That
is, you want a segmenting utility.  Stuffit came with one built in.  (It
can segment any file, not just a stuffit archive.)  Similarly, stuffit
had binhex conversion available.  But just because it isn't built in
doesn't mean you can't use it.  Binhex 4.0 is still free, as far as I
know (and faster than stuffit's implementation), and there are lots of
segmenting utilities out there.  I'm not sure, but I'd bet that some of
them are also free.  With Multifinder available, having everything in
the same application isn't really a necessity.

>I guess this isn't quite so important until Compactor can binhex or
>uuencode, but it will be important then.

Basically, you'll have to decide if the convenience of having the
utilities available from within the application outweighs the better
compression you get with compactor.  Personally, I have nothing against
binhex 4.0.

>Kent Borg                            internet: kent@camex.com   AOL: kent borg
>                                            H:(617) 776-6899  W:(617) 426-3577

-- 
Draphsor vo'drun-Aelf                  draphsor@portia.stanford.edu