Hi Folks:
Not a question here, just observations. We have an IBM running as
a station monitor that runs software that saves log files; about 86
megs a day. It ran out of hard drive the other day. About time I
guess.. I tried sending these to compress. Well, fist I could only
do 1 file, because there was very limited hard drive. But, after 1,
then 2, then 4, etc., and deleting the original files, I could
'compress' about a month's worth of files in a clip. I couldn't
'compress' 2 months, no matter how much free hard drive I had. Using
'compress' I could only do a month at a time. It took about 16 seconds
a file (86 megs) and compressed very tight! A whole month compressed
to about 60 megs! I noticed there is about 2 years of these files to
compress.. That's a LONG time to compress!
I just found PKZIP on a boot chip! Using the CMD window, our good
'ol virtual DOS window, I can 'pkzip' the all these files at once -
over two years worth, and it takes 6 seconds a file. Over twice as
fast in a 'virtual DOS box' it's causing FAR less drive activity, and
I can still use the computer! In fact, I'm deleting the originals
after PKZIP 'zips' them. Why is this?
Harry

HarryHydro wrote:
zip feature in XP to a full production version like PKZIP then I can
easily understand the diff. Also you are comparing a GUI program to a
DOS program. There is always less overhead in a DOS program.

Another thought is to use some backup utility. Normally backup programs
do two things, 1) it will compress the data as it goes, 2) it will span
drives so if you put the backups on DVD's it will let you spread the
backup over quite a few dvd's go get the job done. You just need the
backup to restore and have to remember to keep it for future needs.
And its not as readily viewable like a zip file is.

HarryHydro wrote:

There is PKZIP, as written by Philip Katz, and then there is everything
else. Presumably the verzion of PKZIP that is running in the CMD box is
verzion 2.04 (or 2.X). IMHO, this was the most efficient version and the
best of all the file compressors and expandors. Or, IOW, "slowness" can
be attributed to inefficiency and code-bloat due to lousy programming
plus the additional overhead of the virtual DOS box in itself versus the
Windows CMD box.

You said:


and then you said:
Why is this?

Which was it intended to be?