AppleSingle vs MacBinary?

[hjalfi]

So I've got this FluxEngine thing which lets you read and write exotic floppy disk formats on normal PC drives (with some extra hardware): http://cowlark.com/fluxengine/ It'll do Mac 400kB and 800kB disks.

I'm currently adding support for direct filesystem access, so that you can read and write files directly without needing to image the disk. Naturally, HFS is one of the formats (via libhfs ripped out of hfsutils). However, the Very Special Nature of Mac files is raising its ugly head again. I need a unified way to present both the data and resource forks in a single file. I decided in AppleSingle and implemented it, and AFAICT it works, but further investigation shows that nearly all tooling prefers MacBinary.

I thought that AppleSingle was supposed to _replace_ MacBinary (re https://www.ietf.org/archive/id/draft-newman-macbin-binhex-harmful-00.txt). Did this actually happen? Is MacBinary actually more useful and preferred in the real world?

 

[Ivan Holmes]

First of all thanks for developing FluxEngine - very useful piece of software! I found this post because I was looking for a way to create AppleSingle files on Linux.
I can use unar to decompress a StuffIt archive into AppleDouble, and there are some open source tools (included with Netatalk I think) that allow you to convert the AppleDouble into MacBinary. However, as far as I can tell, there is no way (yet) to create an AppleSingle file on Linux, and I suspect there may not even be on Mac without using the Carbon API which is no longer supported (since 10.15).

So, IMO, based on the IETF note it would be best to support AppleDouble (which is also the format OS X//macOS and Netatalk use to store their resource forks) rather than MacBinary, but either would be better than AppleSingle.

EDIT: After looking in your code, I noticed you have a function to generate AppleSingle files and it's pretty trivial to do so. It might be workable to include a script or small program that makes AppleSingle files from AppleDouble. I think it would still be best (if not too much of a headache) to use AppleDouble though - the 'double' part of the file is usually prefixed with ._ or suffixed with .rsrc, so it should be simple to detect.

By the way, apologies if I am telling you a load of stuff you already know here...

 

[NJRoadfan]

An AppleSingle file is just an AppleDouble file with the data fork embedded in it. If you have the code written for AppleSingle, supporting AppleDouble is easy enough. The reason two files are preferred is that it allows non-Mac platforms to open up a data file as-is, without the user having to parse/strip headers.

Macbinary was popular mostly because it predated AppleDouble by 5 years and became a defacto standard. Once Apple created their standard, people preferred it because that is what the OS supported out of the box (particularly after OS X was released).