From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1ece2318f24b35a7 X-Google-Attributes: gid103376,public From: auryn@rtd.com (Don Yuniskis) Subject: Re: UNIX Compressed Files From A PC Date: 2000/08/13 Message-ID: #1/1 X-Deja-AN: 657818823 References: <3995C90A.E72C055F@acm.org> <3996B1FC.A5892C21@acm.org> X-Complaints-To: Abuse Role , We Care X-Trace: monger.newsread.com 966185051 198.102.68.2 (Sun, 13 Aug 2000 12:44:11 EDT) Organization: none NNTP-Posting-Date: Sun, 13 Aug 2000 12:44:11 EDT Newsgroups: comp.lang.ada Date: 2000-08-13T00:00:00+00:00 List-Id: In article <3996B1FC.A5892C21@acm.org>, Marin D. Condic 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