That explains it. I was trying to run Netatalk 2.x on this system a while back and probably did a `make install` to get it there.
sit - Create StuffIt archives on Unix systems
- Thread starter thecloud
- Start date
I've been tinkering with megatron recently actually. The main reason megatron doesn't work with modern netatalk is because AppleSingle support was removed from libatalk. I have a local branch where megatron is building again with netatalk 4.x but there are some bugs to work through.
If there is interest from the community, we can look into expanding the supported source formats.
A couple of new bug fixes for the New Year have been pushed to the git repository.
1. Using sit to create archives of files from developer CDs and other old content, I noticed that filenames with "high ascii" (option-key) characters weren't being translated properly to MacRoman when expanded, either on classic Mac OS with StuffIt, or with The Unarchiver. You might recall having folders named "Icons ƒ", or files named "Project.π" or "Read Me • Bullet" or "Commercial®App™" or whatever with those extended characters that you needed to type with the option key. Anyway, sit now makes an effort to translate them from UTF-8 to MacRoman so the names are preserved when expanding the archive.
2. A related problem is that if your filename happens to contain a slash '/' character on macOS (i.e Unix), it is silently translated to a colon ':'. But colons are not allowed in filenames on classic Mac OS! They are now translated back to slashes in the file, so the right thing happens when expanding.
3. sit used to always silently overwrite an archive file if it existed. Now it will not overwrite an existing file; instead, it generates a unique filename. So if you already have "archive.sit", it will create "archive-1.sit" instead, and so on (up to 999.)
This version has been tested on Snow Leopard, Sequoia, and Manjaro Linux just because.
1. Using sit to create archives of files from developer CDs and other old content, I noticed that filenames with "high ascii" (option-key) characters weren't being translated properly to MacRoman when expanded, either on classic Mac OS with StuffIt, or with The Unarchiver. You might recall having folders named "Icons ƒ", or files named "Project.π" or "Read Me • Bullet" or "Commercial®App™" or whatever with those extended characters that you needed to type with the option key. Anyway, sit now makes an effort to translate them from UTF-8 to MacRoman so the names are preserved when expanding the archive.
2. A related problem is that if your filename happens to contain a slash '/' character on macOS (i.e Unix), it is silently translated to a colon ':'. But colons are not allowed in filenames on classic Mac OS! They are now translated back to slashes in the file, so the right thing happens when expanding.
3. sit used to always silently overwrite an archive file if it existed. Now it will not overwrite an existing file; instead, it generates a unique filename. So if you already have "archive.sit", it will create "archive-1.sit" instead, and so on (up to 999.)
This version has been tested on Snow Leopard, Sequoia, and Manjaro Linux just because.
Last edited:
I'm actually slowly changing my mind on the question of adding MacBinary support to sit. There are two reasons:
1. A MacBinary-wrapped archive allows the correct type and creator to be set for the archive file itself when reconstituted on a classic Mac.
2. The original author of sit, Tom Bereiter, had it on his roadmap. In the old README file, he says, "It should be quite simple to modify sit.c to put a MacBinary header on the archive."
Also, still need to go back and fix the AppleDouble code so compression happens there too.
1. A MacBinary-wrapped archive allows the correct type and creator to be set for the archive file itself when reconstituted on a classic Mac.
2. The original author of sit, Tom Bereiter, had it on his roadmap. In the old README file, he says, "It should be quite simple to modify sit.c to put a MacBinary header on the archive."
Also, still need to go back and fix the AppleDouble code so compression happens there too.
Why were those annoying “ƒ” characters used in folder names back in the day? I never saw any logical reason for them to be used, and not every company used them.
)
Yes, the ƒ was kind of an odd convention. Seemed to occur in some communities (programmers, BBSers) and not very much in others. I suppose it helped differentiate folders with custom icons from the applications themselves within the folder. Commonplace enough to recognize but not something I ever did myself.
Exactly. But I guess it’s technically Apple’s fault for having started it with “Empty Folder” back in the MFS days and continuing it with “System Folder”. Even though the Mac was all about icons and a “graphical“ user interface, they still wanted to reinforce it with a word. Even so, it’s a big stretch to truncate the word folder into an unusual looking f.
Kinda stumbled across a utility suite that came with the Columbia AppleTalk Package: https://github.com/mabam/CAP/tree/master/contrib/AufsTools
Interesting. They also forked the same sit.c file from 1988, back in 1990. Looks like the only addition is to stick the FInfo in a .finderinfo/<filename> path, where AUFS expected to find it.
Sorry it took so long, but I finally got around to making `sit` read the `com.apple.FinderInfo` extended attribute for file metadata. It's a lot more useful now when archiving a file that doesn't have a resource fork.
for posterity since I mentioned this in the thread earlier, megatron is "kind of" making a comeback the upcoming Netatalk 4.6, only folded into the nad tool as subcommands (nad hex, nad bin etc.)
more on topic for this thread, there is a quite recently created tool and Rust library called stuffit-rs which can read StuffIt 5's "Arsenic/BWT" compression algorithm -- might be worth studying the implementation to expand sit's capabilities!
disclosure: I have contributed some code recently to stuffit-rs, notably a C ABI so that Netatalk can be linked with the Rust library
That's good to hear. There should always be (at least) two ways to do anything.
I know that The Unarchiver (or more specifically the XAD Objective-C library it uses) has support for multiple StuffIt compression algorithms, including Arsenic, Brimstone, Cyanide, and Darkhorse. At some point I'll go back and look to see if it's worth the effort. My main use case for the `sit` tool is to be able to create an archive on a current machine that can be opened on early Mac system versions, and the 1.5.1 LZW/Huffman algorithms are the least common denominator to achieve that. But it might be nice to have the ability to get better compression as an option. I'm also a big fan of self-contained tools with as few dependencies as possible.
It's great that you are also going to be adding MacBinary support. That's next up on my roadmap.
this is the netatalk / megatron implementation of MacBinary, if you want something to compare with
github.com
cannot speak for its correctness; it's built entirely on top of the assumptions of the original author circa 1992
netatalk/bin/nad/macbin.c at main · Netatalk/netatalk
Free and Open Source AFP fileserver for Macs and cross-platform AFP clients - Netatalk/netatalk
github.com
cannot speak for its correctness; it's built entirely on top of the assumptions of the original author circa 1992
Thanks. I've been working from the specification by Peter N. Lewis that's distributed with his MacBinary II application.this is the netatalk / megatron implementation of MacBinary, if you want something to compare with
netatalk/bin/nad/macbin.c at main · Netatalk/netatalk
Free and Open Source AFP fileserver for Macs and cross-platform AFP clients - Netatalk/netatalk
cannot speak for its correctness; it's built entirely on top of the assumptions of the original author circa 1992
Ran into this thread looking for a way to decode hqx/bin files on a Windows machine
This throws more warnings than I'd like for something I need to use in some archival work.
I haven't tried using that macutils code, and it is certainly ancient so I'd expect there are lots of warnings. @rdmark pointed to the somewhat newer source for `nad` in netatalk, where the macbin.c file has bin_open and bin_read to let you read (decode) a MacBinary file. But be aware that a MacBinary file really is like 3 separate concatenated files: the metadata in the file header, the data fork, and the resource fork. You probably want to leave it stored as a MacBinary file for archival purposes, to avoid losing the resource fork on systems that don't support them. What will you be doing with the decoded files on Windows?
I'm happy to store the resource fork in a way that https://github.com/elliotnunn/macresources can read.
To be honest I had a lot of trouble working out how to drive both macutils and nad.
Mostly research - I'll leave my QuickTime adventures for another thread.
Thanks for the reply and thanks for this project.
I had a look at macresources, and unfortunately they have created their own proprietary format to store resource forks that is to my best knowledge not compatible with any other tooling discussed here: you would need to write your own conversion script
In my opinion, for archiving purposes you should use either macOS style “._” sidecars or Netatalk style “.AppleDouble” sidecars for the best portability and cross tool compatibility
Netatalk and nad cannot run on Windows, they’re built with BSD/POSIX semantics and permission model: Linux in a VM would be your best bet
In my opinion, for archiving purposes you should use either macOS style “._” sidecars or Netatalk style “.AppleDouble” sidecars for the best portability and cross tool compatibility
Netatalk and nad cannot run on Windows, they’re built with BSD/POSIX semantics and permission model: Linux in a VM would be your best bet