NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/compress/4573

Text File | 1993-01-11 | 1.8 KB | 41 lines

Newsgroups: comp.compression
Path: sparky!uunet!rei2!fox
From: [e-mail] (Fuzzy Fox)
Subject: Re: An idea for HD compression
Message-ID: <[e-mail]>
Date: Mon, 11 Jan 1993 23:38:18 GMT
References: <[e-mail]>
Organization: Recognition Equipment, Inc.
Lines: 30

[e-mail] (Diversion (Jeff Rogers)) writes:

>Why not try to reclaim this lost space? Use a null-suppression algorithm on
>half-empty sectors, keep an index of them, store them somewhere else in a
>packed form, and get them when they're requested by int 13(?).

I assume you mean to handle this at a BIOS level, where you don't know
what the OS might be trying to do with each sector.  If so, how do you
propose to know which bytes are significant in any sector that's written
to disk?  DOS does not fill unused bytes with zeroes, nor does any other
OS (although maybe VMS does).

>I think this is similar to what stacker does, but I recall hearing that
>stacker operates on ms-dos files only, and doesn't work with other os's

One of the problems that Stacker must deal with, as well as your own
program, is how to deal with the simulation of a disk that has more
clusters than the actual medium.  Say you have a 1 Meg floppy and you
are simulating a 2 Meg floppy.  Suppose a program writes data to every
single sector on the 2 Meg floppy.  Which sectors do you keep, and which
do you throw away?  What happens if the data compression used does not
let you fit all the sectors on the 1 Meg physical medium?  A real floppy
disk cannot return a "disk full" error; that's what the OS does.  You
could return a hard write error, but is that a solution?

--
#ifdef TRUE        | Fuzzy Fox (a.k.a. David DeSimone)       [e-mail]
#define  TRUE   0  |
#define  FALSE  1  |  "911 Emergency Rescue Service - Can you hold, please?"
#endif             |