Archiving best practices and breaking the Seal?

Purdy

New Tinkerer
Oct 28, 2021
18
20
3
I have just acquired a truly massive collection of vintage Mac software from a collector who recently passed away. I will post more details about it later as I inventory the collection but there is a tremendous amount of fully boxed Mac software, with a particular emphasis on the 1984-1993 era. To give you an idea, the first box I inventoried had boxed copies of Deneba Comment 1.1, ThinkTank 128 & 512, ReadySetGo 1.0, FolderBolt, Habadex, Cubase 1.8, Cricket Graph, TOPS, Dollars and Sense and several more.

I want to archive anything from this collection that I cannot readily find on archive.org or MG so that it can be shared with fellow enthusiasts today and in the future. Unfortunately, I have had people (well, one particularly vocal person) take issue with how I archive material in the past, so I am looking for some guidance and a consensus on what are the best practices today.

My initial plan is to archive disk images along with photographs of the box & disks to JPG and scans of any manuals & documentation to PDF.

As for the disk images, floppies will be locked, and imaged using DiskCopy 4.2 on two different Macs. (models TBD, probably a TAM and an 800k Mac SE) Checksums compared. Assuming they match, disk images will be packaged into .sit.hqx and .mar archives. Disks with errors and/or copy protection will be noted and set aside for later review. A full set for each program would consist of a package of box photos, disk photos, .hqx disk image bundle, .mar disk image bundle and any documentation scans) All of this would be uploaded to archive.org. There are also several thousand loose floppies that will be archived similarly, but obviously without the box and documentation.

One other issue of note is that a fairly high percentage (probably 30-40%) of the software is still sealed in the box. This raises the issue of what is best for conservation. Take for example, a sealed copy of THINK Reference 1.0. As far as I can tell, there are no existing copies of this version. My instinct is to break the seal and archive it using the process above. But in other vintage communities, breaking a sealed package is near sacrilege, with the idea that future conservation methods will be better than those of today. (as well as destroying a tremendous amount of value by breaking the seal. I'm less interested in the value issue. If I was doing this for money, I'd have this stuff on eBay already.)

As I said, my hand has been bitten too many times trying to archive vintage software, so I am looking for guidance on both of these questions:

1) Is the process described above the best way to archive already opened software?

2) What should I do in the case of sealed packages?

I appreciate any suggestions or guidance people can provide. I stopped archiving my personal collection and am reluctant to get back into this, but this is truly a once in a lifetime opportunity and I am trying to live by the motto “Illegitimi non carborundum” and get this trove preserved the best way possible.
 
  • Like
Reactions: SteveHere and Mac84

rjkucia

Tinkerer
Dec 21, 2021
233
81
28
Madison, Wisconsin, USA
While I don't have any particular insight into proper archival methods, I think it's much more valuable to the community to have an archive of a piece of software instead of letting it sit in a sealed box. Floppies last a pretty long time, but nothings lasts forever - I'd rather break a seal on something now and archive it than wait another 10 years and find out you can't get a good read on the floppy.

I guess the seal might protect it more - so maybe try to re-seal it when you're done archiving it? Collectors wouldn't like that, but since you said value isn't important to you, I think that's fine.
 
  • Like
Reactions: Patrick

3lectr1c

Active Tinkerer
May 15, 2022
625
292
63
the United States
www.macdat.net
Agree, break those seals! Those floppies won't last available, archiving the data before it rots away is important for preservation.
As for archival, disk copy will work, but for that much stuff you may want to look into investing into a proper dumping rig using something like an AppleSauce or KryoFlux. They allow you to take much lower-level dumps of the disks, and can work around weak/bad sectors far better than a tool like disk copy will.
 

Purdy

New Tinkerer
Oct 28, 2021
18
20
3
Agree, break those seals! Those floppies won't last available, archiving the data before it rots away is important for preservation.
As for archival, disk copy will work, but for that much stuff you may want to look into investing into a proper dumping rig using something like an AppleSauce or KryoFlux. They allow you to take much lower-level dumps of the disks, and can work around weak/bad sectors far better than a tool like disk copy will.
I'm willing to invest in AppleSauce or KryoFlux but will need some more recommendations on which. Naturally both claim to be the ultimate in imagers. My quick research seemed to point towards AppleSauce, but KryoFlux does have one big advantage: it's actually available for purchase right now, whereas it looks like I just missed a production run of AppleSauce. But if AppleSauce is significantly better, I'd rather wait until they are available again. This is going to take months if not years, and I'd rather do it right than quick.
 

MacKilRoy

Tinkerer
Dec 10, 2021
37
16
18
Mac84 is one of the archiving kings of the community. I’d see how he would weigh in on this.
 
  • Love
Reactions: Mac84

Mac84

Administrator
Staff member
Founder
Sep 4, 2021
187
264
63
New Jersey, USA
www.mac84.net
Oh boy, archiving floppies! 💾 Well... *rolls up sleeves*, let me try to shed some light on what I've learned. My apologizes for the book! (There is a TL;DR below)

Introduction

I'm not an expert, but a lot of smart people have helped me over the years. Please be aware that I'm just typing this from my memory, so things may not be exact, etc. Anyone reading this, feel free to correct things. I own both a Kryoflux and an Applesauce and have some novice experience with both.

I can't speak to all forms of copy protection or situations, but generally speaking a modern disk imaging device like KryoFlux or Applesauce will give you the ability to better archive disks with some pretty neat features and recovery options. Both offer the ability to try and re-read any bad sectors you may encounter while reading disks. This is very helpful, as on a real Mac either DiskCopy (or whatever app) usually won't re-try and will simply fail with a generic error that the file or disk couldn't be copied. Also, usually to archive 400K disks, they won't be read on Mac OS 8 or higher (unless using DiskCopy 4.2). So you may prefer System 7.

For years this is what I battled with, and when a file or disk refused to read, I just set it aside and hoped that sometime in the future this would be resolved. Thankfully the Applesauce and Kryoflux do help you to a degree. They won't fix all damaged disks, but I‘be been amazed by what some alcohol and re-trying could do.

IMG_5537.jpg


The Kyroflux:

It uses a standard PC 3.5" floppy drive, apparently I just happened to have one of the Sony model drive that play nice with Apple 800k/1.4 MB disks. I got mine in the summer of 2021 and used it a number of times. Their software is straightforward although you sometimes need to manually select the format, or guess from the drop-down menu. From what I recall "MFM" disk is the format for Macintosh disks (1.4MB) and the "Apple DOS 400/800K" option is reserved for earlier Mac / Apple II disks. I had to hunt around for some details about archiving Mac disks, as most people don't buy it to do that. Also, don't think the secondary port on the Kyroflux is for a Mac floppy drive, although it looks like one may fit!

I've had pretty good luck imaging disks, but have found that some disks confuse the software so they don't know what type of disk it is. It may let you archive it anyway, but it won't identify the disk type/structure. Sometimes these problematic disks would actually read in my vintage Mac just fine. It could be an error of me using the software (very likely) or maybe the disk was kinda messed up (also very likely).

Screen Shot 2021-08-06 at 3.10.31 PM.png
Screen Shot 2021-08-06 at 4.39.02 PM.png


The Kyroflux saves images in .img format, but you have the option to do "preservation" reads of a disk. But I haven't looked into that (although I've used it out of curiosity a few times). These .IMG files will work in a Mac emulator or can be mounted on a vintage Mac (assuming you fix any resource fork issues or file type associations with ResEdit). Overall, the Kyroflux is a neat piece of kit, and if you want to archive Mac or PC disks (and have the right disk drives) it's a good option.

The Applesauce:​

As the name hints, is specifically tailored to Apple systems. Most people probably know it for archiving Apple II disks, but it works beautifully with Macintosh disks too. You just need to supply your own external 19-pin 3.5" 800K or later floppy drive. I've been using one that came with a second hand Mac Plus. Of course you'll need to change out the eject gear, lube up the gears/rails and clean away the decades of dried up crud. But once you've done that, it works beautifully. You can also use a 1.4MB "SuperDrive", but the instructions I found said it must be installed using the adapter board inside Apple external 3.5" 800K drives. Thankfully I had one with a bad drive, so I installed my SuperDrive and it worked well. Giving me the ability to archive 400K, 800K, and 1.4MB disks. I've archived probably 100 disks so far, and the software makes it a breeze.

A very bad disk!
A disk with bad sectors, but 99% of them went away.
A disk that read cleanly


There isn't much guess work as it's designed for Apple and Macintosh disk drives. You can optionally add sensors and such for your disk drives, but I've found it's not needed for the 3.5" disks. There are two main imaging modes, Flux, and Fast imaging.

Flux mode produces a deeper level scan which is best for awesome people to better remove copy protection and analyze the structure of the disks. Their website does a better job of explaining this, so I won't pretend to understand all the benefits. My general rule of thumb is to do a fast image first, then (if it’s a commercial disk) do a flux image, as it takes more time. Most generic disks (unless it contains something interesting), I’ll just use the fast imager process.

The flux image process on Applesauce


Fast imaging is, well, faster! It usually takes under 30 seconds for a 400K disk, about 1 minute for a 800K disk, and a bit longer for a 1.4 MB, assuming you don't need to re-try for errors. The best part is that it gives you the option to retry bad sectors as many times as you want. This gives me the chance to eject the disk, open the shutter, and wipe away grime or put a dab of 91% or 99% isopropyl alcohol to try and eradicate read errors (which surprisingly works every well!). Or clean the heads of the floppy dirve, which you'll want to do very often. Sadly, the Flux option doesn't let you re-try bad sectors. However, wizards on the Applesauce discord were able to combine info from a Flux dump and Fast image dump of my Excel version 1.00 to get it working. So... its magic?

Fast Imaging (and Flux) also let you know if files are damaged or incomplete due to bad sectors. This is VERY handy, as you can figure out if a crummy disk with bad sectors is worth battling or not. It usually is, but it'll give you a heads up if a file is effected or not.

The files with an X show which ones may have read errors. In this example those were copy protection files.


For Macintosh disks Fast imaging lets you save a .dc42 (DiskCopy 4.2 format, basically .img) or .Moof (a bit stream format for geekier purposes like running copy protected software). For Apple II disks you have .WOZ o. The Flux format gives you an .a2r Applesauce file. This contains a bunch of extra fancy info, but can also later be extracted to a .dc42 or .Moof file. Again, the big risk is if the disk is cranky, you can end up with bad reads on a sector (which the visuals will show) and you can't re-try just those bad spots without re-fluxing it, which takes about 2x as long as a normal "fast" image of a disk.

Using a Real Mac

Using a real Macintosh with a SuperDrive and System 7.X is another option. I'd avoid PCs and Linux options just because 800K disks aren't fun to get working on non-Apple systems. I won't argue if it can be done because I've seen some stuff... but I wouldn't rely on it to archive disks.

Using real hardware has some pros and cons however. The preferred app by many is DiskCopy 4.2, as it'll capture "tag bytes" from the disks. Apparently these are usually unused on Mac disks, but for a completionist (and maybe rare cases they are used), that is good to be aware of. Personally DiskCopy 4.2 has been cranky to me and doesn't like most emulators or some Macs. However, apparently it should run fine on most 68K and Power Macs in Mac OS 7, 8 and 9. DiskCopy 6.3 is newer, but won't capture the "tag bytes" from the floppy disk, but it will let you mount disks on your desktop after imaging them. You can also use it to mount most DiskCopy 4.2 images, but ShrinkWrap 3.5 can help with stubborn images.

1BD49101-0570-4FFC-BE07-A1652DA9F8A8.JPG


Unfortunately, when making a disk image from a floppy... 9 times out of 10 the image process fails due to an error. It's probably because a sector couldn't be read and the system doesn't give you the option to retry it. This sometimes this forces me to copy files manually off the disk (which sometimes work fine, others not). But for commercial software this isn't ideal as hidden files and other data may not copy via that method, etc. Now maybe there's a good way of sector-reading floppies on the Mac that I haven't stumbled upon (or remember) it.

I've even used an iBook with a USB floppy drive to image 1.4MB disks, but of course this won't work with older 800K or 400K disks.

What to archive and Unsealing Boxes

My suggestion? Archive EVERYTHING. EVERYTHING!! Is there already a copy on MacintoshGarden? Archive it anyway! The disk image may be missing a file or may be a different version. Not all printed labels are accurate, or maybe your disk has a patched update or Read Me file the other doesn't. It's easier to make a huge stack of disks and just archive them all. It doesn't hurt to have a second copy, because some of these archived may not have been copied right, or may be incomplete (at no fault of the archiver).

You can usually unseal a box carefully, even prying the box flaps open with tweezers to not bend the cardboard, to get to those sweet disks inside. These disks are getting up there in age. Thankfully sealed disks have a better chance of reading fine, but nothing lasts forever. So unless it's something super rare, like Alice: Through the looking glass, you could carefully unseal it and preserve the disks.

Organization and Sorting

Make yourself a spreadsheet to keep track of the disks, it'll keep you sane (...well kinda). I'll share an example here soon. I used a #2 pencil to write on the back to keep track of disks. It'll easily wipe away if needed and won't harm it. But when you have 50 floppies on your desk, everything seems to look the same (especially if they are generic disks). I usually write something like #A22 or #B33 to keep track of batches I work on.

A spreadsheet example for cataloging disks


Once I've attempted to archive the disk I have three bins to place them in. Bin 1 is "100% Good", this means that I was able to archive the disk and even if it had bad sectors, they were eventually readable via cleaning. Bin 2 is "Mostly good" the disk may have read errors, but I've tried my best. I can return to these later if I'm feeling lucky. Bin 3 is "Dead", ether they have too many bad sectors, or they have physical damage. Bin 4 is "Unknown Format", both Kryoflux and Applesauce will shrug if it can't understand a disk, I like to sort these out in case it was user error or it turns out to be something special.

Oh, and certainly take photos or scans of the fronts (and if possible backs) of the disks! Sometimes the back of the disks have a sticker or label with a serial number, version number, or copyright date, which helps date the software.

Nursing Disks to Read

A number of times I'll get the Applesauce going and one disk will be very, very unhappy. It may read initially with 12 bad sectors, but maybe you can get that down to 3 by retrying... but then it gets stubborn. Even if you attempt to re-read a disk a dozen times (I've done it before), they may not budge. Thankfully some 91% or 99% isopropyl alcohol is your friend. Cleaning the heads of the floppy drive and the platter of the disk itself has helped me. You don't want to drench it, but a dab or a swab can be very effective. Don't give up either, sometimes I've had to re-try over a dozen times, but was eventually successful!

An old floppy...
... with some physical damage!

Conclusion (TL;DR)

Both sides will claim they are the best. It's obvious that the Applesauce creators had Apple/Mac users in mind and they have a few unique tricks just for our disks. However, due to supply issues they aren't being sold at the moment (as of January 2023). This leaves the Kryoflux, which will require a power supply, a sorta specific Sony 3.5" PC floppy drive that will mingle with Mac disks, and some bravery to ensure you are selecting the right type/format disk when archiving the disks. Using a real Mac may work well, unless you get some problematic disks with bad sectors.

In a perfect world all of these tools would be easily available to everyone and all disks would read happy. But it's super understandable to have to make a choice between what you can afford (or find) and how much time and effort you want to put into things. Archiving these disks is a great thing to do, and if it's worth doing, it's worth doing right (and spending the time do things properly of course). However, do the best you can and keep your records. That way when you come across problematic disks, or things with copy protection, you can set them aside to send / share with others to try them out. I’d be more than happy to help with my Applesauce.

Both will work well enough with *most* disks that are in good shape. Both will likely let you image a slightly cranky disk... However, I've been more impressed with the Applesauce's abilities to recover bad sectors. That being said, in full disclosure, I just got the Applesauce recently and it's been top of mind. I really should do a comparison video about these little devices. As maybe my memories about the Kryoflux are a bit hazy.

I hope this helps! I'll go back and add images and links soon.
-Steve
 
Last edited:

Crutch

Tinkerer
Jul 10, 2022
293
227
43
Chicago
disk images will be packaged into .sit.hqx and .mar archives.
Sounds like a great find! One detail here, there is no reason to Binhex (.hqx) these images or indeed anything uploaded to preservation sites. The sole purpose of Binhex is to convert Mac files to modem- and tty-compatible ASCII, which blows up file sizes by 150% on average. Here, you just need to combine resource and data forks and Finder information into a single binary file. The format for that is MacBinary (.bin), not Binhex.
 

Mac84

Administrator
Staff member
Founder
Sep 4, 2021
187
264
63
New Jersey, USA
www.mac84.net
Sounds like a great find! One detail here, there is no reason to Binhex (.hqx) these images or indeed anything uploaded to preservation sites. The sole purpose of Binhex is to convert Mac files to modem- and tty-compatible ASCII, which blows up file sizes by 150% on average. Here, you just need to combine resource and data forks and Finder information into a single binary file. The format for that is MacBinary (.bin), not Binhex.
Oh wow, I didn't know this. My mind just blended bin and binhex. Thanks for the tip!
 

MacKilRoy

Tinkerer
Dec 10, 2021
37
16
18
Sounds like a great find! One detail here, there is no reason to Binhex (.hqx) these images or indeed anything uploaded to preservation sites. The sole purpose of Binhex is to convert Mac files to modem- and tty-compatible ASCII, which blows up file sizes by 150% on average. Here, you just need to combine resource and data forks and Finder information into a single binary file. The format for that is MacBinary (.bin), not Binhex.

I believe this is only true with files archived using StuffIt version 5.0 and above. Files compressed with prior versions of StuffIt will corrupt when transferred to a non Mac-HFS system.
 

Mac84

Administrator
Staff member
Founder
Sep 4, 2021
187
264
63
New Jersey, USA
www.mac84.net
I believe this is only true with files archived using StuffIt version 5.0 and above. Files compressed with prior versions of StuffIt will corrupt when transferred to a non Mac-HFS system.
I just stuffed a folder that contained apps and files to a .sit using DropStuff v3.5, v4.5 and v5.5. Once compressed to a .sit (not using Bin-Hex), I uploaded the files to an FTP and then downloaded them on another Mac. Once unstuffed the resource forks remained happy and the apps launched. Yay?
 

MacKilRoy

Tinkerer
Dec 10, 2021
37
16
18
I just stuffed a folder that contained apps and files to a .sit using DropStuff v3.5, v4.5 and v5.5. Once compressed to a .sit (not using Bin-Hex), I uploaded the files to an FTP and then downloaded them on another Mac. Once unstuffed the resource forks remained happy and the apps launched. Yay?

I stand corrected! Were each file of a different size (to prove it's using the different versions to actually compress them)? From what I understand, the DropStuff relies upon the Stuffit Engine in the Extensions folder, and regardless of the version of DropStuff, it will utilize whatever engine is in there to compress/decompress the file.
 

Paralel

Tinkerer
Dec 14, 2022
115
47
28
I just stuffed a folder that contained apps and files to a .sit using DropStuff v3.5, v4.5 and v5.5. Once compressed to a .sit (not using Bin-Hex), I uploaded the files to an FTP and then downloaded them on another Mac. Once unstuffed the resource forks remained happy and the apps launched. Yay?

I find most "modern" versions of StuffIt that have the Stuffit Engine installed as an extension, are able to make SIT files with the main StuffIt Application or DropStuff without worry to the forks.

Also, despite the installer not working, if you install Stuffit 5.5 on System 7.5.x and then move the files and the Stuffit Engine extension back to System 7.1.x, ensuring that you have the Drag-and-Drop, Thread Manager, & 68k-CFM Runtime Enabler 4.0 extensions installed, it will run without any trouble. You also don't need to have 16 MB of RAM. 8 MB of RAM will work, just don't expect to do much else since StuffIt 5.5 will take up 5.9 MB all by itself. On a Classic II with 10 MB of RAM running System 7.1.2 StuffIt 5.5 ran without a problem.

Just as a sidenote, if you install the 68k-CFM Runtime Enabler 4.0 extension make sure to include the ObjectLib 1.8 extension along with it, otherwise it won't work.

Regarding cleaning of media, IPA sounds good, but has anyone determined the best material to clean with? Cotton? Microfiber? Silk? One wants to remove dirt without risk to the ferromagnetic particles on the disk.
 
Last edited:
  • Like
Reactions: Mac84

Patrick

Tinkerer
Oct 26, 2021
434
1
223
43
From what I recall "MFM" disk is the format for Macintosh disks and the "Apple DOS 400/800K" option is reserved for Apple II systems.
This surprises me.

FM and MFM is the format most computers used. Apple (apple II and macintosh) and commodore* used GCR. In addition, Apple liked to do the fancy disk rotation thing. where the drive will spin up or slow down depending on the track to pack more data on a disk. Vs, IBM just had a set speed.
Maybe when making these kind of FLUX type files such details don't matter ?

source:
for disk encoding.

note, apple switched to the industry standard for 1.44 disks. that ^ would only apply to 400/800k disks



My feeling is if it works it works. So better to do what works for you then not at all.
I do prefer disk images of some kind. diskcopy or moof. because those are more universal and one doesn't have to worry about resource forks. If you put it as a SIT it might be kinda hard for me to get it to a retro mac or used in mini vmac. (not impossible, but img is easier to mount and use in most cases)

* not an exhaustive list.
 

Mac84

Administrator
Staff member
Founder
Sep 4, 2021
187
264
63
New Jersey, USA
www.mac84.net
This surprises me.

FM and MFM is the format most computers used. Apple (apple II and macintosh) and commodore* used GCR. In addition, Apple liked to do the fancy disk rotation thing. where the drive will spin up or slow down depending on the track to pack more data on a disk. Vs, IBM just had a set speed.
Maybe when making these kind of FLUX type files such details don't matter ?

source:
for disk encoding.

note, apple switched to the industry standard for 1.44 disks. that ^ would only apply to 400/800k disks



My feeling is if it works it works. So better to do what works for you then not at all.
I do prefer disk images of some kind. diskcopy or moof. because those are more universal and one doesn't have to worry about resource forks. If you put it as a SIT it might be kinda hard for me to get it to a retro mac or used in mini vmac. (not impossible, but img is easier to mount and use in most cases)

* not an exhaustive list.
MFM surprised me too, but I believe it's for the 1.4MB Mac disks. Again the Macintosh documentation for the Kryoflux isn't super detailed. But I think I was using that for 1.4MB disks and "Apple DOS 400K/800K" for 400K/800K Macintosh disks. (I've updated my post to make this more clear, assuming I'm correct. I'm basing it on this GitHub Kryoflux article)

Yes, when I archive disks I usually try to provide all the formats possible (dc42, moof, bin, etc), just so anyone can hopefully have an easy experience using the software.


Regarding cleaning of media, IPA sounds good, but has anyone determined the best material to clean with? Cotton? Microfiber? Silk? One wants to remove dirt without risk to the ferromagnetic particles on the disk.
I've been using cotton buds / swabs, which seemingly haven't hurt anything.
 
  • Like
Reactions: Paralel and Patrick

Paralel

Tinkerer
Dec 14, 2022
115
47
28
I've been using cotton buds / swabs, which seemingly haven't hurt anything.

Thinking about it, regarding determining what is going on with a problematic disk. I would imagine most issues are just plain old dirt, but as we know, floppies can be attacked by mold that eats the PET film, just like VCR tapes. So, that raises the question of, should the offending agent be identified and should different practices be used depending on the offending agent?

At least the actual magnetic particles are of no concern with regard to any changes to its chemical composition. Both 400/800k disk and 1.4 MB disks use ferromagnetic materials that are terminally oxidized. The only issue regarding that is the loss of data retention over time, but that can't be avoided since its a function of physics, just like EPROMs.
 

Mac84

Administrator
Staff member
Founder
Sep 4, 2021
187
264
63
New Jersey, USA
www.mac84.net
Thinking about it, regarding determining what is going on with a problematic disk. I would imagine most issues are just plain old dirt, but as we know, floppies can be attacked by mold that eats the PET film, just like VCR tapes. So, that raises the question of, should the offending agent be identified and should different practices be used depending on the offending agent?

For each disk, before inserting it to the drive, I open the shutter and inspect it briefly to determine if I can spot any scratches, dirty, or mold etc.

After archiving over 100 disks, I haven't seen too much debris, even on disks from the early 1980's. However, some did have dirt and possible mold spots. Those (at least in my case) were easily cleaned with a gentle swipe of a cotton swab with alcohol on it. However I consider myself lucky with this batch so far!
 
  • Like
Reactions: Paralel and Patrick

Crutch

Tinkerer
Jul 10, 2022
293
227
43
Chicago
(Crutch said): Sounds like a great find! One detail here, there is no reason to Binhex (.hqx) these images or indeed anything uploaded to preservation sites. The sole purpose of Binhex is to convert Mac files to modem- and tty-compatible ASCII, which blows up file sizes by 150% on average. Here, you just need to combine resource and data forks and Finder information into a single binary file. The format for that is MacBinary (.bin), not Binhex.

I believe this is only true with files archived using StuffIt version 5.0 and above. Files compressed with prior versions of StuffIt will corrupt when transferred to a non Mac-HFS system.

No, what I wrote is always true and is independent of using StuffIt or not:
  • MacBinary (.bin) combines resource fork, data fork, and Finder information in a single binary file suitable for upload to any modern service.
  • BinHex (.hqx) does the same thing, but outputs an ASCII text file suitable for upload to a legacy BBS via modem. MacBinary and BinHex are not the same. BinHex is much less space efficient due to the need to convert every bit into a part of the subset of possible bytes that represent printable ASCII characters. There is no reason to BinHex anything in 2023!
It is possible that .sit archives already upload nicely without the need to MacBinary (.bin) them, I’m not sure, but they never need to be BinHex’ed. If they need any sort of fork aggregation, use MacBinary.
 
Last edited:

Crutch

Tinkerer
Jul 10, 2022
293
227
43
Chicago
(Strictly speaking I would argue there is no reason to use StuffIt on single files like disk images in 2023 either. Just run MacBinary on it for fork aggregation and archive the .dsk.bin. StuffIt is awful with its many flavors and quietly incompatible variants.)
 
  • Like
Reactions: Patrick and eric

rjkucia

Tinkerer
Dec 21, 2021
233
81
28
Madison, Wisconsin, USA
(Strictly speaking I would argue there is no reason to use StuffIt on single files like disk images in 2023 either. Just run MacBinary on it for fork aggregation and archive the .dsk.bin. StuffIt is awful with its many flavors and quietly incompatible variants.)
Would this be a good summary of how to store/transfer old Macintosh files?:
1) Combine the files into a single (Mac-friendly) file, such as StuffIt or a disk image
2) Convert that single file to a MacBinary (.bin) to preserve the resource forks/metadata/etc (BinHex/.hqx will *work*, but it's objectively worse than MacBinary for modern purposes, unless maybe you're running a BBS in which case you probably know what you're doing anyways)

I agree with StuffIt being frustrating. It doesn't help that they're often uploaded without bin-ing, which makes StuffIt unhappy about dealing with it since the resource fork is stripped. I think I've also encountered scenarios where software that is 68000-compatible is compressed with a StuffIt version that only works on later machines, but that could've just been the resource fork thing too.
 
  • Like
Reactions: Mac84

MacKilRoy

Tinkerer
Dec 10, 2021
37
16
18
Would this be a good summary of how to store/transfer old Macintosh files?:
1) Combine the files into a single (Mac-friendly) file, such as StuffIt or a disk image
2) Convert that single file to a MacBinary (.bin) to preserve the resource forks/metadata/etc (BinHex/.hqx will *work*, but it's objectively worse than MacBinary for modern purposes, unless maybe you're running a BBS in which case you probably know what you're doing anyways)

I agree with StuffIt being frustrating. It doesn't help that they're often uploaded without bin-ing, which makes StuffIt unhappy about dealing with it since the resource fork is stripped. I think I've also encountered scenarios where software that is 68000-compatible is compressed with a StuffIt version that only works on later machines, but that could've just been the resource fork thing too.

Tehcnically speaking, the DiskCopy type images should be uploadable without any .bin, .hqx, or .sit of the file. However, when a user downloads just a raw .img file, the file type/creator is lost, and perhaps some other manipulation is done to the file inbetween.

I like y our idea of making a DiskCopy-type image, and then running it through MacBinary to preserve the file contents. I think MacBinary extraction should be quicker and simpler on a vintage 68k Mac than .sit files that need extraction (which is painfully slow, and often incompatible because various StuffIt versions are not compatible with each other, and files are just ".sit").

For end-user ease-of-use, I do believe StuffIt that is installed with Mac OS 7.5+ can extract .bin files, or am I remembering incorrectly?