• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

How do you store your software (sit? bin.hqx? etc)

JAG

Well-known member
I've put together a small Linux file server for my classic Mac network and can now connect to it over both Ethernet and LocalTalk (via an Asante bridge) with anything from a Mac Plus running 6.0.8 to my iMac running 10.7.

What I'm wondering is, what is the most convenient way to store software on a file server like this?

Some of the stuff I have is in StuffIt 5 format and takes forever to unstuff. Maybe just binhex everything?

The server has everything stored on an ext3 file system. Am I paranoid to worry about losing resource forks on a non-hfs file system or is the netatalk implantation really rock solid enough to not worry about it?

 

Trash80toHP_Mini

NIGHT STALKER
I store everything on CD and HDDs with bootable system installs "for any Macintosh."

Compression . . . I don' need no steeeenkeeng compression! }:)

I could use a better labeling system though . . . :-/

 

Unknown_K

Well-known member
I store then on NTFS formatted hard drives (server) so the resource fork isn't damaged, but most are in *.sit or *.hqx depending on their age. Some files are stored with no compression for easier install. I do own a legit stuffit suite on CD for compressing my own files.

 

bbraun

Well-known member
I keep a similar setup, netatalk on linux backed by ext3, accessible via ethertalk with an ethertalk<->localtalk bridge for the localtalk machines.

My personal preference is to keep .{sit,cpt}.hqx versions as the authoritative copy, and I have an "extracted" subdirectory where I keep extracted copies of the compressed & binhexed versions. The entire "extracted" subdirectory can be blown away if additional disk space is needed, but it serves as a convenient cache for frequently used software so I don't always have to copy locally and extract everything.

As for netatalk's storage, it basically stores the datafork in the file you normally see, then there's an ".AppleDouble" subdir inside every directory, and inside that is the same filename, but it's an AppleDouble file of the metadata for the normal file. It's more than just the resource fork, it also contains the file type/creator code and some other stuff.

This is a pretty simple system, but if you lose the .AppleDouble subdir, or rename files in Linux (or via another sharing protocol other than netatalk), the .AppleDouble files and the datafork file can end up with different names or in different directories and netatalk won't be able to match them up. The system is pretty simple and reliable, if you always use netatalk to access it. But if that's not your usage model, I wouldn't rely on the extracted copies.

I also like to take advantage of netatalk splitting the resource fork and metadata for me, since it's easy enough from a shell on the linux machine to hexdump the appledouble files to easily inspect resources. I used this extensively while working on the bootable romdisk driver. CodeWarrior on the mac would spit out a DRVR resource into a file that lived on netatalk. I then had a shell script on the netatalk server to extract just the actual driver from the netatalk appledouble file and dd it into the ROM file at the right offset.

 
Top