> From: Barry Samuels [mailto:barry@beenthere-donethat.org.uk]
> > > I want to replace one of the modules (98k) within the file
> > > system with
> > > one of my own (68k) but always end up with a compressed
> file system
> > > that is larger than the original and won't fit on the disc.
> > >
> > > Could someone please explain, to a 'bear of little brain',
> > > what I must
> > > be doing wrong?
> >
> > Sounds like the "smaller" module is making the archive less
> > compressable.
>
> That doesn't explain why deleting a file and not replacing it
> makes the
> resultant compressed file system larger.
<stabbing at clues in the dark>
Hmmm, ok what could be happening is that the file is being deleted from the
directory indices but the space on disk is never overwritten with blank data
but still has the original file there just no longer referenced by the
filesystem. This change in the indices etc. causes the compression algorithm
to make a bigger file as there is still data at the same point on the disk.
You could perhaps try creating a new "empty" loopback filesystem and then
copying the data between the two and trying to compress that to see what
happens.
In short thats a guess, apart from that I don't know you could always try
asking on a compression newsgroup :)
> > Try gzip -9 for the best compression (and slowest) and see if that
> > helps it
> > fit.
>
> I've been using -9 all along.
Ummmm, try -8 ;) actually you could try all of them to see if the archives
to get smaller with greater levels of compression. ISTR that in some cases
using a "greater" compression ratio can cause a file to end up bigger than
using a lesser one.
Adam
Adam