I don't know why so many of you cannot read the text when you create a new page for an Application or Game. It clearly states not to use ZIP files. I am seeing more and more lately, so if you cannot create a valid Stuffit 5 archive on your own, maybe request another user on the board do so for you...
This page is a wiki. Please login or create an account to begin editing.
2011, December 21 - 12:00am
#1
Please Stop Using ZIP Files!
Comments
2011, December 21 - 9:55am
#2
If you're referring to mrdav's posts of late, then use MacZip to decompress and they are all A-OK. He also alerts you in his posts that MacZip is what he uses to compress his archives.
Also if it clearly states "not to use ZIP files" in the upload pages, then someone needs to rewrite the "A Beginner's Guide for Uploading Stuff to Macintosh Garden" for the "The image's ready. Is that all?" section. Where it clearly encourages using MacZip for archiving everything except on Disk Copy 6.x files.
It also cites: "...zips are more compatible with all of Macintosh Garden's target platforms (Mac OS 6-9, Mac OS X PPC and Intel, and Windows) and hence, less troublesome. Besides, StuffIt Expander doesn't run well under emulation..."
Anyways, I've used MacZip and Stuffit for so long that it doesn't bother me which way it gets archived and as long as MacZip is used when archiving as Zip, it correctly preserves a Mac file's resource fork in zip archives and runs on a classic Mac OS.
2011, December 21 - 2:10am
#3
All the recent zips I've seen are either mine or mrdav's or Gael's, and they all are zipped disk images that do not suffer any data loss, and can even be opened with StuffIt 5.5 on a Mac. When used with care, the zip format enables users of many different machines, operating systems, and emulators to utilize the same archive.
2011, December 21 - 2:56am
#4
I don't care what form of compression I use. MikeTomTom is spot on. The only reason I use MacZip is precisely because of the statements in the Guide that he quotes. In fact I have never used MacZip before joining Macintosh Garden. If the recommendations quoted from the Guide are inappropriate then I have been mislead. If the Guide is changed to discourage the use of MacZip, then of course I will use Stuffit.
2011, December 22 - 7:47am
#5
I fear we are sliding down a slippery slope with ZIP files, that is all.
Why aren't we using binhexed Stuffit files, as that used to be the accepted method in the old days? (I am worried about getting flamed over this question, please be nice!)
Also, what is the issue with DiskCopy 6.x images and ZIP files?
2011, December 23 - 2:39am
#6
@themacmeister:
Why aren't we using binhexed Stuffit files, as that used to be the accepted method in the old days?
Binhex is OK, but these days it is wasteful. i.e It creates much larger files than the "stuffed" file it may contain so its an overhead you need to consider for those downloading it. Plus, a Stuffit ".sit" is safe as is, as a net archive form. So binhexing a "stuffed" file is wasteful and not necessary.
But you can "binhex" all kinds of Mac files and not just ".sit" and it is a safe method for transporting over the net, so it still is a valid and useful means to do so... Newer generations of Mac users are probably unfamiliar with binhex too, which is likely now just an arcane obscurity at best.
Also, what is the issue with DiskCopy 6.x images and ZIP files?
The issue with DC 6.x images & Zip is as what is outlined in the subsection of the section entitled: "The image's ready. Is that all?" of the Beginner's Guide for Uploading to here.
The description for this contains errors and my earlier hint above about this should be rewritten, is quite serious.
For example: If MacZip was used to both compress AND decompress a Disk Copy 6.x image, the result would be a perfectly extracted, fully intact working DC 6.x image file. As long as MacZip was employed at both ends. MacZip also runs under "Classic" on a PPC Mac OS X too, BTW. So in that sense it is just as valid as using Stuffit on a Mac, right up to 10.4.x for zipping DC 6.x images or any other Mac file that contains a resource fork.
Where both Stuffit & MacZip fail is when their respective archives are extracted on non 68k&PPC Mac OS's. Neither is any good at preserving that #$@!! resource fork there. So there are limitations for both.
A limitation of MacZip ".zip" files are that if zipping a Mac file containing a Mac resource fork, then in order to have that Mac file re-assembled intact at the receiving end, MacZip needs to be used to do the decompression. No other zip utility will be able to because of the unique way MacZip preserves the Mac resource fork for transport in the zip file.
OTOH, if that zipped file contains no usable Mac resources such as pure data like JPEG or TEXT etc, then any zip utility will suffice to unzip. The same cannot be said for Stuffit, which is limited (at times even version dependent) to largely Stuffit being present on Mac or Windows to extract, and if there are Mac resources involved on Windows then its a problem. Zip format is the clear winner here as it is almost a universal across platform standard, not limited to just Mac & Windows.
Better info about Disk Copy 6.x also needs addressing.
For example:
If you create a "Read/Write" DC 6.x image file and you name it with a ".hfv" extension instead of ".img" you can zip it (any zip utility) and then unzip on either Windows or Linux (probably Intel Mac too), it will be instantly recognizable as a disk drive in Basilisk II & SheepShaver. Resource fork preservation in DC 6.x in Read/Write image files are not important in this format. Conversely, you can take an HFS ".hfv" disk image created either by HFVExplorer or Basilisk II etc, move it to a classic Mac OS, drag it onto a DC 6.x icon and it mounts as Read/Write disk image in the Mac Finder.
If you create a "Read/Write" DC 6.x image file and you name it with a ".iso" extension instead of ".img" you can, as above, take it to any other platform and burn the image to CD. Make it an HFS file that you can read write to & you can make custom burnable .iso's for any earlier (than 8.1) Mac OS (& more recent Mac OS's).
How to create an HFS (not HFS+) Read/Write image in Mac OS 8.1 to 9.2.2?
In earlier Mac OS's this step is not needed:
Create a DC 6.x image from a folder choosing a file size below 10MB. Unmount the image if mounted. In DC 6.x choose "Convert Image", nav to where you saved the smaller image file. Choose Read/Write and give it a new file size, the result will be a large writable HFS container (choosing Full CD size gives a nice container of 650MB which you can fill up and burn).
2011, December 22 - 11:14am
#7
DiskCopy 6 images use their resource fork for vital information and are destroyed by zipping.
There are plenty of ways to screw up an archive using various versions of StuffIt also; we just have to keep an eye on fresh uploads and make sure they work for everyone. My initial concern with uploaded zips is always to check and see if someone used Mac OS X to make it; those zips won't open properly in Mac OS 9 or earlier, unless it's a disk image that is unaffected by zipping, like Toast or DiskDup+, which is what I use. DiskCopy 4.2 seems to survive okay too.
2011, December 23 - 4:24am
#8
Slightly off topic, but what is the best application for creating .bin files (not .hqx).
2011, December 23 - 10:06am
#9
@xeter: There have been at least 4 revisions of MacBinary ".bin". Perhaps the most compatible to use here would be the MacBinary that Stuffit uses in Stuffit Lite 3.5 & 3.6 or Stuffit Deluxe 4 or newer. Available via their "Translate" menus, under "MacBinary, Encode/Decode" submenus. I suggest Stuffit because most of "us" have the Expander at least and as long as the "Stuffit Engine" or better is also installed, then they will be able to decode ".bin" OK.
2011, December 23 - 10:15am
#10
Apple use/d .bin for their Mac OS downloads so I figured that would be pretty good, but the only .bin making apps I could find on here were from the mid 80s which didn't inspire confidence.
Another 6.0 earthquake in Cch this afternoon, glad you're in Australia, Mike?
2011, December 23 - 10:27am
#11
glad you're in Australia, Mike?
Nah, wish I was in "The Bay" for Christmas but won't be getting over there 'till Feb. Was planning to head Sth from there tho'. I'm a little apprehensive of visiting CCH but, as it is on the agenda.
2011, December 23 - 10:38am
#12
@MikeTomTom -- you the man Mike! That was the best explanation I have ever read - thanks for taking the time to type it all out.
@Mike, if you are in Australia, pop down to Tasmania -- we got a guest room if you need somewhere to crash -- you can also have that G3 iBook and Beige G3 (with ZIP drive).
2011, December 23 - 11:05am
#13
@themacmeister: I am ashamed to say that I have never been to Tasmania (as yet) so thank you for that kind offer. Be warned, I may one day take you up on it 
I would love to visit your state.
Cheers & Merry Christmas.
2011, December 23 - 11:19am
#14
.bin is a less memory intensive way of protecting files over the internet, like what .hqx does. It seems redundant to use with StuffIt, but is useful for Compact Pro .cpt or just a plain DiskCopy 6 image or a .sea self-extracting installer.
2011, December 23 - 11:48am
#15
The upload instructions here say to use .bin or .hqx with images etc., tried .hqx and found it made the files larger than the original image, so that's why I wanted to know how to make .bins.
Mike, I've got a couple of friends live in different suburbs in Chch and there's been no significant trouble in their areas, so it just depends where you want (or have to) go.