Stuffit Deluxe 7.0.1 Extremely Slow
Christopher W Aiken
slow. I started a new archive to compress a 1GB directory at
the max compression level and it took 1 hour and 15 minutes to
complete!!! Since it took so long I opened up a Terminal.app
and used "tar -czvf name.tgz directory" to generate a tar file
archive of the same directory "gzipping" ( the -z option ) each
file. The tar process only took 8 minutes. The resulting file
was within 1MB of the Stuffit file.
I should have saved my money and not purchased Stuffit Delux.
Not much use for creating compressed archives of directories
when it takes that long. Even Winzip and PkZip on IBM compatible
PC's don't take over an hour to compress a 1GB directory.
BTW... I'm using an 800MHz PowerPC G4 iMac with 500MB ram.
--
-=[cwa]=-
e-Mail: chris at cwaiken dot net
Home: www.cwaiken.net
Jerry Kindall
<cwa...@nospam.com> wrote:
> Has anyone purchased Stuffit Deluxe 7.0.1? I find it extremely
> slow. I started a new archive to compress a 1GB directory at
> the max compression level and it took 1 hour and 15 minutes to
> complete!!! Since it took so long I opened up a Terminal.app
> and used "tar -czvf name.tgz directory" to generate a tar file
> archive of the same directory "gzipping" ( the -z option ) each
> file. The tar process only took 8 minutes. The resulting file
> was within 1MB of the Stuffit file.
>
> I should have saved my money and not purchased Stuffit Delux.
> Not much use for creating compressed archives of directories
> when it takes that long. Even Winzip and PkZip on IBM compatible
> PC's don't take over an hour to compress a 1GB directory.
Let's see... you chose the compression setting that essentially means
"take a really long time but compress the archive as much as you can."
Lo and behold, StuffIt took a really long time but compressed the
archive as much as it could!
There just ain't no pleasing the public. Some people bitch if the
software doesn't work, others bitch if it does...
--
Jerry Kindall, Seattle, WA
http://www.jerrykindall.com/
matt neuburg
use...@jerrykindall.com wrote:
> In article <slrnb1764q....@bigdaddy.local>, Christopher W Aiken
> <cwa...@nospam.com> wrote:
>
> > Has anyone purchased Stuffit Deluxe 7.0.1? I find it extremely
> > slow. I started a new archive to compress a 1GB directory at
> > the max compression level and it took 1 hour and 15 minutes to
> > complete!!! Since it took so long I opened up a Terminal.app
> > and used "tar -czvf name.tgz directory" to generate a tar file
> > archive of the same directory "gzipping" ( the -z option ) each
> > file. The tar process only took 8 minutes. The resulting file
> > was within 1MB of the Stuffit file.
> >
> > I should have saved my money and not purchased Stuffit Delux.
> > Not much use for creating compressed archives of directories
> > when it takes that long. Even Winzip and PkZip on IBM compatible
> > PC's don't take over an hour to compress a 1GB directory.
>
> Let's see... you chose the compression setting that essentially means
> "take a really long time but compress the archive as much as you can."
> Lo and behold, StuffIt took a really long time but compressed the
> archive as much as it could!
Plus of course the tgz file has thrown away all the HFS+ metadata,
creation dates, resource forks, etc., whereas the Stuffit archive keeps
all that. As Jerry rightly implies, it's a question of priorities; if you
don't care about that stuff then by all means make a tarball. m.
--
matt neuburg, phd = ma...@tidbits.com, http://www.tidbits.com/matt
*** REALbasic: The Definitive Guide! 2nd edition! ***
http://www.amazon.com/exec/obidos/ASIN/0596001770/somethingsbymatt
Christopher W Aiken
Duh... Unless I'm missing something, the "tar" files (with my above command)
will copy EVERYTHING. No files/directories/resource forks are skipped.
If it didn't archive all files I would be out of a job. It also preserves
times, dates, etc. ( UNIX 101??? ). You have to tell tar which files you
want to exclude and I didn't specify any "excludes". Isn't HFS+ the file
system? What does that have to do with compression? Both Stuffit and tar
are on the same computer and compressing the same files on the same file
system.
I also tried Stuffit with normal compression and it only took 1 hour a
savings of 15 minutes. Also, if you read my post, the compressions must
have been almost the same since the resulting files were only 1MB different.
My Stuffit Preferences are also set to NOT compress files that are already
compressed. tar with the -z option doesn't have that ability, it compresses
or tries to compress "compressed" files anyways.
So, as far as I'm concerned, the question was not answered. Why is Stuffit
so slow?
Howard S Shubs
Christopher W Aiken <cwa...@nospam.com> wrote:
> Duh... Unless I'm missing something, the "tar" files (with my above command)
> will copy EVERYTHING. No files/directories/resource forks are skipped.
> If it didn't archive all files I would be out of a job. It also preserves
> times, dates, etc. ( UNIX 101??? ). You have to tell tar which files you
> want to exclude and I didn't specify any "excludes". Isn't HFS+ the file
> system? What does that have to do with compression? Both Stuffit and tar
> are on the same computer and compressing the same files on the same file
> system.
Hm. I just tried this with a game. Created a gzipped tarball, restored
it elsewhere, and ran it. No problem.
--
Today, on Paper-view: The World Origami Championship
matt neuburg
> Duh... Unless I'm missing something, the "tar" files (with my above command)
> will copy EVERYTHING. No files/directories/resource forks are skipped.
> If it didn't archive all files I would be out of a job
Well, I challenge you. I'll send you a small Classic application, stuffed.
You unstuff it and see if it runs. If it does, then tarball it and send me
the tarball. I'll tell you if I can unzip it and run it. If I can then
I've learned something; if I can't then you're out of a job. m.
Christopher W Aiken
>
>> Duh... Unless I'm missing something, the "tar" files (with my above command)
>> will copy EVERYTHING. No files/directories/resource forks are skipped.
>> If it didn't archive all files I would be out of a job
>
> Well, I challenge you. I'll send you a small Classic application, stuffed.
> You unstuff it and see if it runs. If it does, then tarball it and send me
> the tarball. I'll tell you if I can unzip it and run it. If I can then
> I've learned something; if I can't then you're out of a job. m.
>
Sure, I'm game. Send it to me at my email below.
Christopher W Aiken
Well Matt you were right, grovel, grovel, grovel... I was able to unstuff the
99 Bottles you sent me but I was not able to tar up the exec and get it to work.
More grovel, grovel, grovel,... Why is it that I can not open the sit file
in Stuffit Deluxe? Stuffit Expander takes over and unstuffs the file but if you
try and use Stuffit Deluxe to "open" the file I get an error 17541?
Grovel, grovel, grovel,... Looking for employment....
matt neuburg
I don't understand about why SD can't open the sit file but Stuffit
Expander can, since they use the same engine - indeed, there may be
something wrong with your installation, which could help explain the slow
speeds that started this discussion.
However, that's irrelevant to the matter at issue, which is that unix
tools like "tar" (and "cp", for that matter) don't know squat about HFS+
metadata and resource forks. Unfortunately, in Mac apps and files, that's
often where the functionality is. Thus, tarring the app I sent you
destroys it. This is what I was trying to get you to realize - and now you
do. That's why special tools like "hfstar" and "cpMac" have been invented,
by the way. m.
Bruce Grubb
Enough <eno...@idontcare.com> wrote:
> In article
> <matt-03010...@adsl-64-162-177-73.dsl.lsan03.pacbell.net>,
> ma...@tidbits.com (matt neuburg) wrote:
>
> > I don't understand about why SD can't open the sit file but Stuffit
> > Expander can, since they use the same engine - indeed, there may be
> > something wrong with your installation, which could help explain the slow
> > speeds that started this discussion.
>
> Well, one simple explanation would be if SD and SE were different
> versions. Eg, I have SD 6.5 BUT SE 7.0.1 (I'm cheap, sue me). I doubt
> they use the same 'engine.' A sit file in the new format (sitd?) would
> open with SE 7.0.1 but NOT SD 6.5.
new format is .sitx, sitd (creator) is relatively old being around since SD
5.x IIRC.
Avery Raskin
OK, then, you're fired. AFAIK, tar files do not preserve resource forks,
ergo they do not contain the resource forks. Stuffit was designed to
maintain the integrity of Macintosh forks.
> I also tried Stuffit with normal compression and it only took 1 hour a
> savings of 15 minutes. Also, if you read my post, the compressions must
> have been almost the same since the resulting files were only 1MB different.
Well, that's assuming the files are preserved. In any case, I just
tarred and stuffed a 2.3 MB eps file to see what would happen. First of
all, they compressed in about the same amount of time. I'm not pulling
out a stopwatch - sorry. Second, the tgz file was 10 percent bigger than
the sit file (1.2 MB versus 1.1 MB) which seems to imply better
compression for Stuffit. And finally, after decompressing, the SIT file
was totally intact, including the resource fork, which contained a
custom icon preview of the file. The tgz file decompressed into a folder
containing two files and another folder. The folder is empty, yet
somehow takes up the same size as the resource fork for the compressed
file. The file itself has no resource fork. The third file starts with
the @ symbol and has no value at all I can see. In other words -- it's
hash, although the EPS file will still open in Illustrator. Did I
mention you're fired?
> My Stuffit Preferences are also set to NOT compress files that are already
> compressed. tar with the -z option doesn't have that ability, it compresses
> or tries to compress "compressed" files anyways.
In my experience, zipping files (note, not tarring and G-zipping, just
zipping) is faster than stuffing them, but stuffing is generally more
compressed. Sometimes a lot more, sometimes a little more. At the very
least, stuffing will gain you a 10% reduction in file size. Zipping
often creates no savings at all, especially with compressed files such
as graphics.
> So, as far as I'm concerned, the question was not answered. Why is Stuffit
> so slow?
Why does the moon look round? Answer, it doesn't. Sometimes it's round,
sometimes it's crescent shaped, sometimes it's half-moon shaped. Depends
on the time of month. With compression, it depends on the settings of
the compressors and the files being compressed and what else is going on
with the system at the time.
Mike Hutchison
S.Deluxe7 does have 2 other compression levels, a fast one, a normal compress
level, and of course the 3rd is Stuffit X = max. compression.
Try the faster one next time (see prefs panel), Christopher.
--
Regards,
Micheal Hutchison
Email: Mad...@graphixmad.plus.com
Mac-Troubleshooter+OE FAQ: www.graphixmad.plus.com