The best way to ensure the resource forks are preserved is to use a Mac that
supports the Apple Double system (which is what they called the dual forks) and
pack those files into Stuffit archive files. If a Stuffit archive loses its
resource fork, later versions of Stuffit can still extract them. The Stuffit
files may be moved through any other system without problems.
Do NOT use Self-Extracting Archive! .SEA files are beyond recovery if they lose
their resource forks. That's why .SEA files were always encoded with MacBinary
.BIN or BinHex .HQX so they could be moved around as text files.
BinHex actually started on CompuServe as a way to send binary files because not
all of CompuServe's servers and routers were 8 bit 'clean'. Some of the main
Internet systems also were that way. Since the bulk of data that was sent
across the Internet in its early years was English text, the amount of data
sent could be reduced by 1/8 simply by assuming the (IIRC) least significant
bit was always zero, as it is for all the ASCII characters used in English.
Try to send a binary file through that, where some bytes have LSB that's 1, and
you get garbage on the other end. BinHex encodes each byte to one or more 7 bit
ASCII characters, which does increase the file size, but ensures it will pass
cleanly through any server or router that converts all LSB's to zero. (There
should not be any such still in active use.)
MacBinary uses a larger alphabet of text characters, where some have LSBs that
are 1, so the encoded file size is about the same as the binary original.
MacBinary (and UUencode and other similar schemes) were used to post binary
files to USENET and to bypass e-mail filters that blocked executable or all
non-text attachments.
Many Mac software websites used to have two or three test files to download,
one in MacBinary, one in BinHex and sometimes a 'bare' Stuffit archive. the
object of that was to try downloading the archive, then the BIN then the HQX,
to see which format of the big download you could get without corruption. If
you couldn't download any of them cleanly, your next step was calling the ISP
to find out what they were doing that was corrupting your downloads.
From: Derek Morton <thes...@comcast.net>
To: vintage-macs@googlegroups.com
Sent: Tuesday, July 26, 2016 6:55 AM
Subject: Multi-fork Support or How to upgrade your OS without getting
(de)Forked
Hey all…
This is kind of a vintage/modern question but it seems likely the vintage group
will be able to better answer the questions I have as vintage folks are likely
to have modern experience but the reverse is not necessarily true.
I have a XServe Raid hooked up to a G4 XServe running 10.4.x which I have used
as a file server. Over the years I have stored files from a bunch of computers
(mostly Quadras) onto this system. I chose 10.4 because (if memory serves)
10.4 was the last OS to properly (fully) support multiple forks in files. I am
now setting up a Plex media server and would like to re-purpose the XServe RAID
for media storage (at least until I outgrow it). I have a new (to me) 2009
XSserve running 10.11.x which is running the Plex software.
Here (finally) are my questions:
Am I correct in that 10.4.x is the last OS which fully supports the classic Mac
OS multi-fork architecture (no lost resource forks or corrupted files)?
If I connect the XServe Raid to the new XServe and copy the files to another
store point will I corrupt the files in the process?
Would I be able to make a disk image of the drives without losing anything?
Is there any harm (to existing files) in just connecting the XServe Raid to a
10.11.x system?
I can always get the G4 to perform the backup, but would like to connect the
XServe Raid to the new XServe so I can use the excess capacity for storage as I
copy over countless DVD’s and Blu-Rays.
I still have my multitude of 68K computers and would prefer to not lose the
programs stored on my XServe Raid.
Thanks for whatever assistance or thoughts you can offer in this regard.
--
--
-----
You received this message because you are a member of the Vintage Macs group.
The list FAQ is at http://lowendmac.com/lists/vintagemacs.shtml and our
netiquette guide is at http://www.lowendmac.com/lists/netiquette.shtml
To post to this group, send email to vintage-macs@googlegroups.com
To leave this group, send email to vintage-macs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/vintage-macs
Support for older Macs: http://lowendmac.com/services/
---
You received this message because you are subscribed to the Google Groups
"Vintage Macs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vintage-macs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
