Do StuffIt 5.5 archives encode the resource fork safely for transfer to a non-Mac ?

[MacOSMonkey]

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!"

 

[olePigeon]

That’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.

 

[NJRoadfan]

My 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.

 

[LaPorta]

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.

 

[NJRoadfan]

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.

 

[LaPorta]

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.

 

[Iesca]

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.

 

[bigmessowires]

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.

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.

 

[ymk]

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.

Zip is the most sensible option for CD images.

 

[Crutch]

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.

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 …

 

[LaPorta]

Zip 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.

 

[LaPorta]

Yes that's basically it. Different needs for different purposes.

Come to think of it, why is that you can't use .imgs with FloppyEMU?

 

[Phipli]

I'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.

 

[LaPorta]

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.

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.

 

[MacOSMonkey]

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.

 

[bigmessowires]

Come 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).

 

[LaPorta]

You can; both DSK and DiskCopy 4.2 IMG files are supported (for Macintosh).

Shows what I didn't know!

 

[ymk]

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.

That and bundling BIN images with TOC/CUE files, manuals, case art, etc.

 

[Iesca]

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.

 

[ymk]

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.

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.