Re: UNIX Compressed Files From A PC

[auryn@rtd.com (Don Yuniskis)]

In article <3996B1FC.A5892C21@acm.org>,
Marin D. Condic <mcondic-nospam@acm.org> wrote:
>Don Yuniskis wrote:
>> Are you looking for files that have been compress(1)-ed, freeze(1)-d,
>> zip(1)-ed, gzip(1)-ed, bzip2(1)-ed, etc.?  The algorithms used differ.
>> 
>I am told the files were compressed via "compress" and that it uses the
>LZW compression algorithm.

OK.

>> I assume you *really* mean a "package" and not some other solution
>> to your problem (i.e. unpacking them outside *your* application).
>> If you want to be able to *write* to the packed files, then you obviously
>> either want them to be unpacked before you access them or "wrap" the
>> open/close with unpack/pack...  ?
>> 
>Let me clarify. I want a package, as in "Ada package", that I can
>compile and link to which does Open/Read/Write/Seek/Close for compressed
>files. I could use a C++ class - possibly an extension of the MFC
>"CFile" class - that would do the same.

Understood.

>I think you're confused about the "write" thing. If you are familiar
>with the Win32.LZExpand package in the Win32ada bindings (or the same
>stuff in the Win32api) these OS routines do *exactly* what I need - but
>refuse to do anything with Unix ".z" files. They will work with files
>compressed under NT just fine. The "write" of which I speak is a matter
>of wanting to open a file for output, write bytes to it, close it and
>have a compressed file when I'm done. I don't think it would be very
>easy to do both reads and writes to a sequential file of bytes even if
>it wasn't compressed and I can't imagine trying to do that with a
>compressed file. :-)

Yes, this is why I was noted wrapping the open/close with uncompress/compress
(to give the illusion of a regular file for R/M/W access)

>> The sources to all of the compressors/decompressors in popular use
>> are readily available (though almost always written in C)
>> 
>A URL or two may come in handy. I can cope with it being written in C. I
>can even cope with it being extremely badly written in C, provided I get
>two things: A) The Open/Read/Write/Seek/Close functions I need where I
>send it a file handle and get back a buffer full of bytes (or the other
>direction) and B) It functions reliably so I don't have to debug it and
>hammer on it to get it to work.

Here is the URL for the command line version (under UN*X) of a
compress/uncompress (same executable does both functions):

ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/src/usr.bin/compress

You'll have to peel out the getopts(3) related crap but the core
of the compressor and decompressor are present and have been
"working" for years... :>

Source is tiny -- about 9KB ... much of which you will discard.

Note that the URL places you in a source tree so if you need to
find other files (e.g., #include-d header files) you can navigate to
them using the "parent directory" link...

>My problem in this case is time. I've got a program that is accessing

Heh heh heh... s/My/Everyone/g    :>

>files through a bunch of standard issue Windows calls where
>Open/Read/Write/Seek/Close are the functions being used. I need to make
>a change to the software so it can pick up files across a network from a
>Unix box where the files are compressed. I can't change the requirements
>and I don't have a lot of time to get a solution in place, so I thought
>if I had either an Ada package or C++ class that did the same things, I
>could "leverage software reuse" by simply plugging in the new package
>with maybe a little glue software around it. If you know of something
>that fits this description, please let me know. Thanks.

Understood.  Sorry this won't "drop-in" without a bit of cobbling...

You might also explore the option of running a proxy process on the UN*X 
box that does the uncompress(1) for you "on-the-fly" -- *if* your
requirements will tolerate that -- and just makes the decompressed
file available to you WHILE YOU NEED IT (and then effectively
deletes it -- even if it only existed in VM at the time)

HTH,
--don