APFS and future-proofing files with resource forks

[tanaquil]

I feel like this must have been discussed somewhere, but I've searched this and other sites without much luck so far. If there is a good thread somewhere, please point me to it!

I keep the main copy of my classic Mac software collection (images, sits, isos, etc...) on my 2017 MacBook Pro, carefully isolated from the Dropbox folder where I store almost everything else (I learned long ago that storing classic mac files in Dropbox risks corruption, if not immediately, then the first time I re-download a file on another machine). I'm still running Sierra, within which resource forks are safely preserved. Of course, I need to use various workarounds to mount images or read HFS-formatted disks or whatever, but I can store, copy, move, unstuff etc. all the files on my computer without worrying about whether the files are resource fork sensitive or not. 

It's getting to be time to upgrade to High Sierra (pretty soon we'll be at 10.14 Higher than a Kite Sierra...) but I am worried about the APFS file format. Does it still preserve resource forks properly? Do I need to make sure all of my classic Mac files are wrapped in a dmg or something? Of course I have my archive backed up six ways from Sunday and will keep a pre-High Sierra backup in any case, but I'm wondering about how I should treat files going forward.

Related question: when you store your stuff on a personal server, what future-proofing archival practices do you use? Stuffit? Bin? Hqx? Dmg wrapper? Even if APFS is still resource fork aware, I want to look ahead to the day when that feature goes away, as it surely will. I've read the uploading guides on Macintosh Garden and such but I wonder what best practices others use to store and manage their personal software collection.

 

[uyjulian]

APFS will store Finder Info and Resource Forks just fine.

To archive stuff, I use the builtin utilities of macOS to create zip files and extract them. You can also use "tar" to save directories with their extended attributes, resource forks, and Finder Info.

 

[tanaquil]

Belatedly - thanks for the reassurance on APFS, it is much appreciated.

You haven't had any trouble with creating zips in macOS? I have seen a lot of zip files containing files with destroyed resource forks, but they may have been created/unzipped on PC computers, or maybe the files were damaged before they were zipped. It's possible that zip is safe as long as both the computer used to zip and the computer used to unzip are macs. 

I'll have to try out tar files as well.

 

[nglevin]

I think dmg is probably the most future proof, in the sense that it will still be supported by OS X/macOS for some time. It's more likely that a future macOS release will stop reading HFS+ disk images than it will destroy resource forks from read/write disk images. And HFS+ isn't going away soon, it's still the default for macOS on classic, spinning plate style hard drives.

If you're paranoid, I suppose you could make the dmg disk images read only.

As for others...

OS X zip files store resource forks, but as you've pointed out, those can be accidentally destroyed by unzipping the files on not-Mac OS X.

sit and sitx have always handled resource forks well, though I believe they have the same downsides as OS X zip files in that the forks get wiped away when you unzip the files on a PC.

.bin, AppleDouble and AppleSingle don't really suffer from the PC problem, although OS X removed the AppleDouble conversion tools around the Sierra timeframe. 

rsync based solutions like Dropbox will only handle resource forks as well as the rsync implementation on their OS does. The rsync that ships with High Sierra is still 2.6.9, which doesn't handle them at all. Version 3.0+ allegedly does but expect the forks to be stripped the instant you rsync to a file system that doesn't support resource forks (anything but HFS, HFS+, APFS). I suspect using a newer rsync won't help Dropbox, since it's unlikely they have Macs handling their storage on the cloud.

 

[NJRoadfan]

A netatalk server can handle resource forks. They are saved as separate "dot" files using the AppleDouble method. Note that zip files created on OS X usually store resource forks as AppleDouble as well. I would tend to keep the files on a file system that is resource fork friendly though, no chance of the "dot" files getting orphaned.

 

[Rasmus]

Something I learned today, which makes sense, is that if you create a .dmg in High Sierra on an APFS system, you get a APFS-formatted .dmg! This is of course obvious, but somehow it hadn't occurred to me. They're fine for people running Sierra or High Sierra, but anyone using OS X 10.11 and earlier is out of luck when they try to open them.