68kMLA Classic Interface
This is a version of the 68kMLA forums for viewing on your favorite old mac. Visitors on modern platforms may prefer the main site.
| Click here to select a new forum. | |
| Do StuffIt 5.5 archives encode the resource fork safely for transfer to a non-Mac ? | |
| Posted by: MacOSMonkey on 2023-09-14 09:36:20 I support the same evidence-based/ease-of-use conclusion about .hqx and would like to see repo sites mass convert their file libraries to make them more usable by everyone (which is always a good thing) and also enforce a best practice of requiring .hqx uploads (or auto-convert .sit on upload). From my perspective, you can either use .sit, then stand on your head and stick your finger in your ear while trying to play "She Drives Me Crazy" by the Fine Young Cannibals on a vintage electric harmonica clogged with 35-year-old MacWorld debris from Moscone Center in the hope that the file will decompress properly in PC/emulator conversion scenarios (but it usually won't)...or just use .hqx which always works. Is there a better or easier solution for more universal compatibility? I would really love to see a solution to this problem so that the repos could be more useful. I am also a fan of .zip and .iso, but don't take that the wrong way. š But...not unlike crashing a plane in Chuck Yeager Flight Simulator, I say to you, chaotic .sit uploads, via a little Chuck Yeager pop-up:  "You're no friend o' mine!" | |
Posted by: olePigeon on 2023-09-14 10:29:37Thatās a pretty good reason.I think Fetch v3 and v4 will by default auto-encode to HQX when you upload. I seem to recall that at some point MacBinary and HQX overlapped and just became the same thing. Something like MacBinary III is actually just BinHex 4 or something like that. | |
Posted by: NJRoadfan on 2023-09-14 14:31:31My current theory is that this is to do with FTP and line ending conversions and the horrible FTP "text file" mode. FTP is a menace.DING DING DING. Its this, but with web browsers. A similar problem exists with Apple II Shrink-It archives too. Basically the web browser thinks Apple II and Macintosh compressed archives are ASCII text and helpfully inserts line feed characters after every carriage return (MS-DOS uses CR/LF combo for line breaks). See: https://gswv.apple2.org.za/a2zine/DownloadHelp.htm There was a tool called "Uncook" that would attempt to fix this if it happened. My workaround was to use a FTP client if it was on a FTP server since I could force them to BINARY mode. | |
| Posted by: LaPorta on 2023-09-14 14:55:53 I have yet to have a real problem with this on Macintosh Garden, etc. Do a lot of people really have an issue with this? I may not because I have a 100% Mac setup, new to old. The issue I always have is when people upload files in ā.dskā format and I canāt get anything to open it. | |
| Posted by: NJRoadfan on 2023-09-14 15:13:28 I have the same problem with the Garden. I mean there are ZIP files on there that you are expected to open on a classic Macintosh with a specific extractor because they use a pre-OS X way of storing resource forks. I was around in the 90s. People never used ZIP archives on a Mac since they weren't friendly for storing forked files. Back then, major software companies distributed software as Stuff-It or BinHex.... mostly because the file corruption problem mentioned above was widespread. I think web browsers have gotten better at this... finally. Files named ".dsk" sound like a disk image of some sort, but what is the format? To me, ".dsk" is usually a DOS 3.3 ordered 5.25" disk image for the Apple II. Granted, I could look at the file in a hex editor to figure out what it is, but once again, I really shouldn't have to do that. Disk Copy 4.2 files (a popular image format) generally use the .dc42 or sometimes .dc extension. | |
| Posted by: LaPorta on 2023-09-14 16:20:38 I think the .dsk thing has to do with emulators. Apparently vMac, Basiisk, etc can use them and mount them. However, real Macs have an issue with them. I think itās just a use case divide: if you are emulating everything, you want the .dsk files. If you have all period hardware, you donāt. At least that is my understanding, but I may be wrong. | |
| Posted by: Iesca on 2023-09-14 17:21:46 As a regular contributer to the Garden I almost always use StuffIt 1.5.1 to ensure it can be opened in early OSes, and binhex, out of habit. (It was the most common encoding format for Macs in the early internet, at least that I encountered.) I'm not sure of the origin of .dsk, but in almost every case I can just treat it like a .img or .image file from Disk Copy. Which, btw, I almost always use Disk Copy 4.2 (or more specifically, DiskDup saving in dc42 format), both from a preservation standpoint, but also again for backwards compatibility with early OSes that can't run Disk Copy 6 (and MountImage only recognizes 4.x image files). I really wish uploaders would not use Zip for anything pre-OS X, it's just an extra hassle, and there's no real benefit. | |
Posted by: bigmessowires on 2023-09-14 17:32:39I'm not sure of the origin of .dsk, but in almost every case I can just treat it like a .img or .image file from Disk Copy. They are similar but not identical. Both are disk images, and can be used with emulator software (e.g. Sheepshaver) and emulator hardware (e.g. BMOW Floppy Emu). IMG is usually a DiskCopy 4.2 or DiskCopy 6.3 image, which includes a header with some metadata as well as the actual disk contents. DSK is just the raw disk contents, nothing else. A DSK of an 800K disk will be precisely 800K, an IMG of an 800K disk will be something like 812K. I think itās just a use case divide: if you are emulating everything, you want the .dsk files. If you have all period hardware, you donāt. At least that is my understanding, but I may be wrong. Yes that's basically it. Different needs for different purposes. | |
Posted by: ymk on 2023-09-14 18:05:57I really wish uploaders would not use Zip for anything pre-OS X, it's just an extra hassle, and there's no real benefit. Zip is the most sensible option for CD images. | |
Posted by: Crutch on 2023-09-14 19:07:46I seem to recall that at some point MacBinary and HQX overlapped and just became the same thing. Something like MacBinary III is actually just BinHex 4 or something like that.Sort of true! But I think respectfully irrelevant. .hqx (Binhex 4) is an ASCII format, the whole point of which is to turn Mac files into plain text files (and thereby expands everything by about 50%). MacBinary is a binary format that just combines forks and Finder info and doesnāt waste space like .hqx does. While it is an interesting point of history that the later Binhex 5 used the MacBinary format, basically nobody ever used Binhex 5 for anything. Binhex 4 is definitely not MacBinary. The best way to share a single Mac file today is just to MacBinary it and do nothing else. There is certainly no reason to use StuffIt, god forbid. multifile packages are another matter ā¦ | |
Posted by: LaPorta on 2023-09-14 19:31:07Zip is the most sensible option for CD images.I'd say that .cdr (or the PC .iso equivalent) makes most sense. No need for zip, they work regardless. | |
Posted by: LaPorta on 2023-09-14 19:32:00Yes that's basically it. Different needs for different purposes.Come to think of it, why is that you can't use .imgs with FloppyEMU? | |
Posted by: Phipli on 2023-09-14 19:42:44I'd say that .cdr (or the PC .iso equivalent) makes most sense. No need for zip, they work regardless.The reason is to save server space and transfer time. CDs are often full of empty space, so you can compress it out, without editing the CD. | |
Posted by: LaPorta on 2023-09-14 19:47:38The reason is to save server space and transfer time. CDs are often full of empty space, so you can compress it out, without editing the CD.I suppose if compression is the goal, then yes. I just figure a lot of these old CDs are actually....?200 MB, so not a big deal. Good point. | |
| Posted by: MacOSMonkey on 2023-09-14 19:48:56 The forensic analysis and peer discussion is always interesting and useful, but the solution is simple: just don't upload .sit files - binhex them so that they retain integrity during transfers and so that Expander still works. And as for binhex-related expansion, does it really matter in our modern Moore's Law evolved world? Gone are the days of dial-up and $3000 XP40 40Mb SCSI drives. Ultimately, what matters is universal file integrity and cross-platform/emulator usability/portability. And we don't have that level of functionality or compatibility at the moment, sadly. | |
Posted by: bigmessowires on 2023-09-14 21:28:04Come to think of it, why is that you can't use .imgs with FloppyEMU? You can; both DSK and DiskCopy 4.2 IMG files are supported (for Macintosh). | |
Posted by: LaPorta on 2023-09-14 21:44:00You can; both DSK and DiskCopy 4.2 IMG files are supported (for Macintosh).Shows what I didn't know! | |
Posted by: ymk on 2023-09-14 22:18:43The reason is to save server space and transfer time. CDs are often full of empty space, so you can compress it out, without editing the CD. That and bundling BIN images with TOC/CUE files, manuals, case art, etc. | |
| Posted by: Iesca on 2023-09-14 23:54:21 You can zip cdr images if you like, most people I suspect are not going to try and mount a cdr within System 7 or earlier. And a cdr doesn't have a resource fork anyway. | |
Posted by: ymk on 2023-09-15 00:22:50You can zip cdr images if you like, most people I suspect are not going to try and mount a cdr within System 7 or earlier. For System 7 software, they will probably burn the CD image to disc or copy it to an SD card using a modern machine. That's why zipping a CD image makes more sense than putting it in a .sit, which I've seen more than a few times. The purpose of zip isn't to preserve resource forks. It's to save several hundred MB in storage/bandwidth and group files. | |
| < 3 > |