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.