• Hello, Guest! Welcome back, and be sure to check out this post for more info about the recent service interruption and migration.

StuffIt 5.5 doesn't always extract .sit files fully

Juror22

Well-known member
@Crutch Yeah, there really needs to be a consensus on an official archival compression format. Not only that, but it needs to be enforced.
I totally agree - I have a Basilisk slice that I use almost exclusively for unpacking all the items that should unpack, but don't.
Compact Pro (.cpt) archives
I love this product! ROCK solid and always works.
StuffIt 1.5.1 for archiving, all the way!
I would vote for this as a must for anything done with Stuffit.
 

Spidey01

Well-known member
StuffIt Expander can expand .cpt files too.

We are stuck with the multitudes of StuffIt files all over the Garden and elsewhere …. But there is no reason to ever, ever make any more of them!
Expander 5.5 can but told me to install Drop Stuff, which I found as a Segmented archive that requires Drop Stuff or an older Deluxe (so the archive with the segments said) to rejoin. Once I solved *that* pain in my butt: StuffIt unpacked the .cpt archive and was missing files on System 7.5. I was doing this to install SetDate to work around the 2k20 problem on my Duo, and ended up copying the files to an HFS floppy, after extracting it from a MacOS 9.2.2 machine.

I kind of like that StuffIt is so flexible. It seems to alleviate the need for having BinHex/MacBinary/MacZip on my system, and even has proven helpful in trying to mount disk images. But StuffIt definitely been a pain in my butt.

You might summize and even approve that I’m not using StuffIt files beyond extracting them or achieving the ones I’ve downloaded. I’ve no desire left to make any more of them. I thought I would, after I got Expander working the first time. But nope, definitely nope.
 

Iesca

Well-known member
I’ll admit, I’ve never seen or dealt with CPTs. What program makes them?
Compact Pro!

 

Crutch

Well-known member
Agreed! Compact Pro self extracting archives are the best way to compress vintage Mac files if you can spare a few K for the extraction code overhead.
 

olePigeon

Well-known member
I wonder if we could convince Norton, Smith Micro, or Cyclos to donate the source code to their older copies of DiskDoubler, Stuffit / DropStuff, or CompactPro to the Gryphel Project, Archive Org, and/or Computer History Museum. Then we could standardize on one of those with the security of knowing the code could potentially be adapted to other platforms for helping to preserve and archive vintage Macintosh software.
 

Cory5412

Daring Pioneer of the Future
Staff member
This is an interesting thread.

I like stuffit, personally, I think it's fine, and, I agree -- the fact that the files aren't completely backward compatible is tough.

I've never seen any evidence that they are not completely forward compatible, so what we're here is ultimately a symptom of two things:
  • File compression techniques got meaningfully better during Stuffit's lifetime and the company took advantage of new techniques when releasing new software
    • To add to this point: Stuffit wasn't meant for long-term historical preservation. It was a file management tool that has its roots in the specific computing environment of the '80s and '90s and most of its foibles come down to the way people interacted with it and with Macs in those decades
    • Stuffit happened to be fine for some of the role it got in the early years of the Internet but most of that was because every single Mac magazine cover disc was still shipping with the newest version of the expander, and the expander was included in the OS and with most commercial software and with packs like the apple internet connection kit
  • People contributing to software archives didn't necessarily prepare their files with an intent to be used where they are, and, may not have taken into account what other people have or what their workflows are like
    • I can't think of any other reason why someone would put vintage mac software into a rar or .tar.gz file or why someone would have tried to image a boot CD with toast.
Those two things together mean that most vintage Mac software archives come across as ill considered overall, because, well, they are. Almost none of these projects have a single person actually setting standards, and even if there is, people aren't following them. This is even true on vtools.

Today, the only reason to use any of these tools is either:
  • you have personal nostalgia for the tool
  • you are using server software that is not aware of vintage Mac files
    • This, specifically, is why I tend to prefer running Classic Mac OS and OS X 10.2/3/4 servers for my vintage macs and on bridge machines, and having this available is a lot of why I am running vtools.
Macintosh {Garden|Repo|GUI} et al are absolutely a case of the latter.

Ultimately, once standards are decided, someone needs to take on the work of unpacking things using the newest available versions of all these tools, and then repacking them to whatever standards are chosen based on what's appropriate for any given piece of software. e.g. Word 1.0 for the original Mac may not make sense as a zip file, but Word 2004, which only ran on OS X, might.

I suppose the other option is to write new file compression and expansion utilities for vintage Mac and modern computers, but, to be honest, I tend to think that there's no good or compelling reason to, say, need to open a stuffit 5 archive on my modern computer.

My opinions on this largely stretch out to cover other forms of this topic, i.e. CD imaging and floppy imaging, with the caveat that CD imaging should probably go toward making an ISO on a Windows computer with a tool like imgburn -- I recently found out that the "Virtual ISO utility" works on system 7 for 68k so I don't see any reason to produce CD images in any other format, if that turns out to be true.

Which, another point on this whole thing: I think some of this is going to require research and trial and error.

My recommendation, cc @Crutch and @olePigeon is to make a thread in the vtools forum to propose a 68kMLA/vtools standard file compression method. My current practice there is to leave files untouched but it feels like as good a place as any to start the discussion. (If you want, I can start that thread.)

The next thing after that will be to write documentation, including rationale, for why what was picked was picked, and then start converting things.

We can't enforce standards on other communities, but we can use them here!
 

LaPorta

Well-known member
re: what Cory said:

The images I sent to vTools were all in "System-context" formats, as I would call them, meaning that stuff that would be used on System 6 and up through 9 is either in Stuffit 1.5.1 format (for compatibility up and down), or Disk Copy 4.2 format. This way, if you have later Stuffit or Disk Copy, you can open it, and if you have older versions it should work fine, too.

For CD/DVD images, mine are all .cdr format (basically an ISO), made under Disk Tools on my iMac G4 with OS X 10.4. All of these, even the System 7-based ones, mount fine under OS X, or under System 7-9 with the aforementioned utility that Cory mentioned (though the ons I use is Virtual CD/DVD-ROM Utility), and it works just perfect: mounts and is recognized as a legitimate disc for those games/programs that need the disc inserted.

Whatever people decide, that is fine. The above is just what I did for maximum compatibility for archives being readable on machines that they would be used on.
 

NJRoadfan

Well-known member
What grinds my gears is that people put classic Mac software in ZIP files, or some weird image format that was never used on the Mac.... past or present. I seem to recall having to find one "special" ZIP extractor to handle one of the archives there when just putting it in ANY StuffIt (even StuffIt X) would have been better.

Back in the day, Mac software was usually posted for download in StuffIt format, usually with the option of a BinHex copy (hqx). Occasionally a publisher would post stuff in MacBinary II (bin). The bigger problem I had was classic MacOS's very rigid enforcement of filetype/creator. Applications literally wouldn't let you select a generic binary blob to extract until you set the correct type.
 
What grinds my gears is that people put classic Mac software in ZIP files, or some weird image format that was never used on the Mac.... past or present. I seem to recall having to find one "special" ZIP extractor to handle one of the archives there when just putting it in ANY StuffIt (even StuffIt X) would have been better.

Back in the day, Mac software was usually posted for download in StuffIt format, usually with the option of a BinHex copy (hqx). Occasionally a publisher would post stuff in MacBinary II (bin). The bigger problem I had was classic MacOS's very rigid enforcement of filetype/creator. Applications literally wouldn't let you select a generic binary blob to extract until you set the correct type.

I think it's amusing when new uploads are still compressed for some reason. I've been doing all of my preservation uploads in the .dsk format with a system folder installed. That provides direct compatibility to all 3 emulators. From there if someone wants to extract just the software it's as simple as writing the floppy with a Greaseweazle / Flux Engine or sending it to a Floppy Emu / Scsi2SD.

We're talking about rounding errors in storage space using an entire 800k for a .dsk image versus creating a .sit that is 200k with the amount of hard drive / cloud space we have in 2021.
 

Iesca

Well-known member
For a single file, compression is of course not really necessary these days, but if it's a folder or multiple items, it's a convenient way to combine into a single file for encoding (which is still a necessity for pre-osx).

That said, I'm just as guilty of compressing disk images before encoding; force of habit I suppose!
 

Spidey01

Well-known member
For a single file, compression is of course not really necessary these days, but if it's a folder or multiple items, it's a convenient way to combine into a single file for encoding (which is still a necessity for pre-osx).

There in lay the distinction between an archiver and a compressor: it's just we rarely care any more. ZIP and StuffIt formats are both. By contrast archive formats like Unix's tar only really serve to pack up multiple items into one archive and leave the compression to be someone else's problem (gzip/etc) to compress the entire archive.

Any decent tool that does both archiving and compressing will usually have the brains to say screw it and forgo compression when it's not really effective. Thus few people care until the archiver is guessing seriously wrong about what it should store versus compress.

Thanks to storage becoming so cheap over the years, I tend to care more about archiving than compressing files. Preserving a set of files with integrated integrity checking, basic metadata preservation, and virtually idiot proof moving/copying makes archives useful. Saving network and device transfer times for compression had more of a place when networks were slow and failure prone.

I think it's amusing when new uploads are still compressed for some reason. I've been doing all of my preservation uploads in the .dsk format with a system folder installed. That provides direct compatibility to all 3 emulators. From there if someone wants to extract just the software it's as simple as writing the floppy with a Greaseweazle / Flux Engine or sending it to a Floppy Emu / Scsi2SD.

We're talking about rounding errors in storage space using an entire 800k for a .dsk image versus creating a .sit that is 200k with the amount of hard drive / cloud space we have in 2021.

I've actually found it interesting how often the disk images I've encountered are for 800K. Even for programs that would fit on a single high density disk I'm often encountering a pair of 800K images. Kind of comforting to know if I ever wind up with an older Mac that doesn't speak modern floppy that making disks will be a little less painful.
 

Iesca

Well-known member
I've actually found it interesting how often the disk images I've encountered are for 800K.
Obviously original media should be archived as it is, 800k or otherwise, but if a disk image needs to be made for something, if it can run on something pre-SE, it should be on 800k. And if it's intended for pre-Plus, it should be on a 400k image!
 
Obviously original media should be archived as it is, 800k or otherwise, but if a disk image needs to be made for something, if it can run on something pre-SE, it should be on 800k. And if it's intended for pre-Plus, it should be on a 400k image!
I’ve been working with a lot of 1985 programs lately and it’s interesting how many programs have weird “poor” coding and only work on certain System versions.
 

Iesca

Well-known member
I’ve been working with a lot of 1985 programs lately and it’s interesting how many programs have weird “poor” coding and only work on certain System versions.
And yet some programs were so well programmed, that they work all the way through 9, or even Classic Mode!
 
Top