3

I'm working on a website that is supposed to store compressed archive files for downloading, for different platforms (Mac and Windows).

Unfortunately, the Mac version of the download uses "resource forks", which I understand is a vendor-specific feature of the MacOS file system that attaches extra data to a file identifier. Previously, the only solution was to create the Mac archive (at that time a .sit archive, specifically) on a Mac, and manually upload both versions.

I would now like to let the website accept only the Windows file (a regular .zip that can be decompressed on any file-system), and generate a Mac archive with resource forks automatically. Basically, all I need is some way to generate an archive file on the Linux server (in any reasonably common format that can support resource forks; not sure if .sit is still the best option) that will yield the correct file structure when decompressed on Mac. As the file system doesn't support forks, the archive probably has to be assembled in memory and written to disk, rather than using any native compression tool.

Is there some software that can do this, or at least some format specification that would allow implementing it from scratch?

hippietrail
  • 15,848
  • 18
  • 99
  • 158
Christoph Burschka
  • 4,467
  • 3
  • 16
  • 31

1 Answers1

4

(1) Resource (and other "named") forks are legacy technology in macOS. While still supported, no modern software uses resource forks for anything substantial. I'd first suggest reviewing your requirements to see if this is even necessary anymore.

(2) macOS has long settled on .zip as the standard / built-in archive format. .sit was a third-party compression application (StuffIt) that has drifted out of favor.

(3) Resource forks are translated to non-native filesystems using a naming convention. For example, lets say the file Chart.jpg has a resource fork. When macOS writes this to a filesystem that doesn't support named forks it creates two files: Chart.jpg and ._Chart.jpg, with the latter containing the resource fork and metadata. Typically all that's required is for the .zip file to contain these two files and macOS unarchiving utility will reassemble the original file, with both forks.

I found some files with resource forks and compressed them using macOS's built-in compression command. Here's the content of the archive (unzip -v Archive.zip):

Archive:  /Users/james/Development/Documentation/Archive.zip
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
 1671317  Defl:N  1108973  34% 12-19-2009 12:09 b1b6083c  svn-book.pdf
       0  Stored        0   0% 01-30-2018 12:59 00000000  __MACOSX/
     263  Defl:N      157  40% 12-19-2009 12:09 9802493b  __MACOSX/._svn-book.pdf
     265  Defl:N      204  23% 06-01-2007 23:49 88130a77  Python Documentation.webloc
     592  Defl:N      180  70% 06-01-2007 23:49 f41cd5d1  __MACOSX/._Python Documentation.webloc
--------          -------  ---                            -------
 1672437          1109514  34%                            5 files

So it appears that the special filenames are being sequestered in an invisible __MACOSX subfolder. All you'd have to do is generate a .zip file with the same structure and it would be reassembled on a macOS system into a native file with a resource fork.

James Bucanek
  • 3,299
  • 3
  • 14
  • 30
  • Thanks very much! Now I still need to work out how to actually encode the resources into the fork, but this is a big step forward. (This is a legacy format for an old software that isn't open source, unfortunately - no way around it.) – Christoph Burschka Jan 30 '18 at 23:06
  • Trying to generate or manipulate a resource fork on a non-Mac system is a non-trivial task. (Heck, since resource forks have been long abandoned trying to create one on a Mac is tricky enough.) I think your best/only solution is going to be to extract the resource fork data from a working file and simply duplicate it. – James Bucanek Jan 31 '18 at 00:10
  • 1
    For that part, I actually found a terse but helpful documentation of the format that is enough for a simple implementation: https://developer.apple.com/legacy/library/documentation/mac/MoreToolbox/MoreToolbox-99.html :) – Christoph Burschka Jan 31 '18 at 23:57