home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!mcsun!sun4nl!alchemy!accucx!nevries
- From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
- Newsgroups: comp.compression
- Subject: Re: DELETE PROTECTION AND FILE FIX UNDER ON-THE-FLY COMPRESSION
- Message-ID: <2984@accucx.cc.ruu.nl>
- Date: 13 Aug 92 12:05:24 GMT
- References: <i12.1@cs-acad-lan.Lakeheadu.Ca> <1992Aug11.172604.29703@ncsu.edu> <169b62INNemt@agate.berkeley.edu>
- Organization: Academic Computer Centre Utrecht
- Lines: 29
-
- In <169b62INNemt@agate.berkeley.edu> bho@ocf.berkeley.edu (Bing Ho) writes:
-
- >I find it interesting that somebody would use pklite or diet or lzexe
- >on a stacked drive, since stacker does about as well. Furthermore,
-
- For larger .EXE .SYS .COM files diet etc do better. Anyone using Clipper
- will be very glad about that :-).
-
- >I have found that archive programs actually store a higher density
- >of information (when storing larger numbers of files)than stacker alone
- >because of the ever-present cluster allocation problem. Stacker helps
- >somewhat by the 8k clusters, but there are still limitations.
-
- This is not the main reason. The main reason archivers etc do better than
- Stacker is the speed vs ratio limit. Stacker is faster than most
- archivers but therefore has a worse compression ratio. Also notice there
- are compressors even slower than ARJ with more compression. The limit
- seems to be the Ashford compressor taking hours for an file at about
- 30% more compression than ARJ (see comp.compression FAQ for more info).
-
-
- Nico E. de Vries
- _ _
- O O USENET nevries@cc.ruu.nl FIDO 2:281/708.1 COMPUSERVE "soon" ????
- o This text reflects MY opinions, not that of my employer BITECH.
- \_/ This text is supplied 'AS IS', no waranties of any kind apply.
- Don't waste your time on complaining about my hopeless typostyle.
-
- "I would admit my mistakes, if I had any ..." (Bumper Sticker)
-