E-Maculation

Since Netatalk no longer ships with the megatron utilities (hqx2bin, macbinary, single2bin, unbin, unhex, and unsingle), what tools do you use, on Linux, to convert among MacBinary, BinHex, AppleDouble, and AppleSingle formats? I've seen a few projects on GitHub, but none of them look like finished, working command-line utilities.

Thanks,
-sam

The Unarchiver or its CLI counterpart unar can handle at least MacBinary and BinHex.

unar seems to be broadly available as a binary package.

Another mature library that can process old school Mac data formats is nulib2

What's your usecase for operating on AppleDouble and AppleSingle data? Contemporary netatalk retains all of the built-in AppleDouble metadata support for shared AFP volumes, and you can use for instance the "ad set" command to manipulate AppleDouble.

For transparency, I'm one of the present netatalk maintainers. We briefly contemplated bringing megatron back but decided against it for multiple reasons, one being that other mature options exist like unar or nulib2.

dmark wrote: Sat Oct 04, 2025 11:13 am The Unarchiver or its CLI counterpart unar can handle at least MacBinary and BinHex.

unar seems to be broadly available as a binary package.

Another mature library that can process old school Mac data formats is nulib2

What's your usecase for operating on AppleDouble and AppleSingle data? Contemporary netatalk retains all of the built-in AppleDouble metadata support for shared AFP volumes, and you can use for instance the "ad set" command to manipulate AppleDouble.

For transparency, I'm one of the present netatalk maintainers. We briefly contemplated bringing megatron back but decided against it for multiple reasons, one being that other mature options exist like unar or nulib2.

I've never actually worked with nulib2 directly, but unar is awesome... for what it does. Unfortunately, unar is focused on extracting data, not converting data. So if you need to create a MacBinary, BinHex, AppleDouble, etc. file on Linux, it's not a good choice. I used to use nulib, but that'll only handle Apple II-style image and file compression formats. Does nulib2 expand on that?

I've ended up with my own personal toolbox on Linux that contains a bunch of overlapping tools to handle file format conversion for Apple and Mac legacy formats -- I've found that any single tool generally gets me most of the way there without being able to do it all.

dmark wrote: Sat Oct 04, 2025 11:13 am What's your usecase for operating on AppleDouble and AppleSingle data?

I kinda wandered away from the particular project I was working on that needed this, but if I recall correctly I was trying to use Linux to get a Mac application out of a .bin file and onto a netatalk share in a runnable state, without involving a Mac or Mac emulator.

I see now that unar will give me AppleDouble files, so I'm guessing it'd be a simple matter of renaming ._file to .AppleDouble/file … assuming I'm using ea=ad on the netatalk server. (But I might be using ea=sys? I haven't thought that through yet.)

Anyway, I was hoping there was a single tool that could help here, but it's fine that there's not.

If netatalk's megatron toolsuite solves a problem for you that can't be solved with unar or other tools, I'm happy to look into reviving it. The code compiled last I tried last year. If I can get help testing it that would be great.

edit: Quick update. While it was trivial to get the MacBinary and BinHex conversion working, AppleDouble and AppleSingle will require a lot more work. Between netatalk v2 and v3, AppleSingle code was removed altogether, while the AppleDouble internal data structure changed significantly. I'll keep tinkering with it.

I found myself asking a similar question and stumbled upon this fairly recent thread. Here's my use case, for what it's worth:

I'm compiling a classic Mac application on Linux using Retro68. Retro68 outputs my app as both MacBinary and AppleDouble. Then I'm copying it to my netatalk 4.4.0 server, also running Linux.

If I copy the AppleDouble files as "Program" and "._Program" into my netatalk share directory (following the pattern of other files that are created when copy files using an actual Mac), netatalk doesn't like it when an actual Mac accesses it. If I try to launch the app, it crashes. If I try to open it with ResEdit, it tells me it's corrupted beyond repair.

If I copy the MacBinary file instead, and extract it with unar and then manually rename the generated "Program.rsrc" to "._Program" and do "touch Program" to create an empty file representing the data fork, it shows up as a good file on a real Mac with good resource fork contents, but I have to use ResEdit to assign a type code of APPL and whatever creator code I want before I can launch it. unar's extracted file definitely shows "APPL????" so I know it's there in the AppleDouble data somewhere. It seems like netatalk just doesn't recognize it.

What I've been doing for now is just extracting the MacBinary file using StuffIt Expander on an actual classic Mac (or Basilisk II) that has the netatalk share mounted. That's pretty clunky and slows me down though.

I am not sure if the old megatron suite creates AppleDouble files in the exact correct format that netatalk is expecting, but it seems that netatalk is fairly picky about it. What's the easiest way to get my program directly into netatalk from the Retro68-generated output? I'm tempted to make a quick AppleDouble conversion script by comparing the ordering of the chunks in Retro68's file versus one created by netatalk, but I was wondering if I'm doing something wrong.

Ahh, I researched more and realized that xattrs are also involved, at least in my case. That's where the actual Finder info seems to be stored with my particular Netatalk config.

I did come up with a solution for my use case though. It's a little silly, but it seems to work and is faster than what I was doing:

• Have Retro68 output AppleDouble and MacBinary.
• Decode the MacBinary file on the netatalk server using a real Mac or emulator; just have to do this once to put a good app on the server.
• Make a simple converter script that takes Retro68's AppleDouble output and reorders it so the Finder info (ID 9) comes first followed by the resource fork (ID 2), matching what netatalk does. The reason for this is because Retro68 outputs them in the opposite order.
• The converter script also puts the "Netatalk" identifier (followed by spaces) in place from offset $08 through $17.
• Whenever I build my app with Retro68, follow it up by running the converter script, and then copy the output of the converter over the top of the "._AppName" file on the netatalk server.

Now netatalk sees the correct updated resource fork contents, and the xattr stuff is already safely stored in the filesystem from the initial MacBinary extraction, so a real Mac will immediately see that everything is still good and it will see the updated resource fork data. I'm not sure how safe this actually is, since I'm going behind netatalk's back. But it seems to work with my limited testing!

I found "maconv" project, but not sure if it works correctly (tried to extract macbinaryIII format NewWorld rom file, it seems to work, but result is not that DPPC expects ..)

https://www.macintoshrepository.org/dow ... hp?id=9746

https://github.com/ParksProjets/Maconv/

Github page contain version that does not build with ggc 11.2.0 as in Slackware 15.0

But I guess you can get patches from pull requests, if you can't extract srpm

good news: I have a fully working port of megatron in bleeding edge netatalk now

not quite merged to main yet, but you can try the code from here: https://github.com/Netatalk/netatalk/pull/3052

I rebuilt the meta data backend to use libatalk/vfs properly, so it can now read and write Netatalk EA natively, in addition to AppleDouble v2

there are a handful of additional major changes to how the application functions:

- did away with the symlink invocation in favor of positional subcommands (akin to how Netatalk 'nad' works -- see the table in the PR)
- added support for BinHex encoding (it could only decode BinHex before)
- quiet operation by default, opt in to the traditional chatty mode with the '--verbose' flag
- will now read afp.conf to determine if it is operating on files inside an AFP volume, which is how it picks whether to convert to EA or AppleDouble
- will update the Netatalk CNID database, assigning CNIDs to files that are created by megatron
- we now only allow megatron file operations inside an AFP volume

the last point may be controversial; my justification for this design decision is that the AFP volume configuration is what decides which target format to convert to (AppleDouble or EA)

secondly, it's arguably messy to leave a trail of .AppleDouble dirs and sidecar files all over your file system after using megatron for a while

do you all see a recurring use case for doing megatron file conversions in arbitrary file system locations that are not under a AFP volume path? I am happy to try to find a good solution if you feel strongly about this

after code review and debate in the Netatalk dev team, we have landed on a somewhat different solution:

'megatron' no longer exists as a separate tool, but its functionality has been folded into the Netatalk nad tool (formerly known as 'ad').

if you're not familiar, 'nad' allows you to perform file system operations on a Netatalk host's AFP volume directories and have it update the AppleDouble sidecar / xattr as well as CNID database for you, effectively emulating how an actual AFP client would operate and not break the consistency of the files on the AFP volume

in addition to 'nad mv', 'nad rm' and so on, we now have 'nad bin', 'nad hex', 'nad unbin', and 'nad unhex' subcommands

I also introduced an option to allow nad operations outside of AFP volumes, by adding the '--force' flag to your nad commands

this is all in the bleeding edge netatalk main branch, will be included in the upcoming v4.6.0 release!