Some older versions of Windows Server, when Services For Macintosh were installed, had a command called "forkize". What it would do is if you were storing Mac files on a Windows Server, was repair the relationship between a data and resource fork.
Of course you had to have both forks. I don't know if you could take a broken file and copy the forks to Windows Server and 'forkify' them, then reach out over the LAN to bring the file back whole to a Mac.
I've always found it very odd that no such utility has been made for Macintosh. If you have both forks, undamaged, it should be possible to 'glue' them back together - especially when Microsoft figured out how to do it on an 'alien' operating system. Also, Stuffit Expander will automatically create new resource forks for Stuffit archives that have lost theirs. But that one is easy since a Stuffit resource fork is nothing but the Type, Creator and an icon.
Quicktime for Windows is a curious case. On Mac, MOV files have resource and data forks, same as most others. Normally, to copy a MOV to any other system you'd have to have Quicktime Pro, which enables the "flatten" function. That bundles the resource fork into a single file with the data.
There's another way. Put a .mov extension on the file name then copy the video to a PC format drive. It's easiest to only have the one video file on it. Connect the drive to a WinBox then look in the other folders (which are hidden on a Mac) for the resource fork file. Copy it and the .mov to the same folder then add a .qtr extension to the resource fork name. The rest of the name before the extension must be identical.
Doubleclick the .mov file and Quicktime will use the data from the .qtr file to play it. Great, but what about flattening MOV on Windows? QT Flattener.
http://www.macdisk.com/quickten.phpThe takeaway is that for most Macintosh files it is only safe for them to travel away from home when bundled up warmly in a thick Stuffit archive or wrapped cozily in BinHex or MacBinary text encoding.
Why are there two different text encoding formats? That goes back to the early days of the Internet when it was mostly a concern of the English speaking world and most of the information going back and forth was text files and e-mail. To save transmission time and data usage (remember this was when a 20 *megabyte* hard drive was huge) the early net gateway computers were configured to not pass the 8th bit of all the bytes, unless receiving specific commands that the file going through was Binary Data - not text. For all the characters needed to write anything in English, the 8th bit is 0. So it could be ignored until arrival at the destination, where *magic happens* and a 0 got stuck onto every byte, or e-mail client software just worked with 7 bit text. If you sent an image or a program file and didn't set things to command the gateways to not strip the 8th bit, the destination got garbage - kind of like a teleporter mishap...
https://www.youtube.com/watch?v=Ro_QpDJX-SkI'd have to look up which of the format is which, but one uses only 7 bit ASCII characters while the other uses more characters which require all 8 bits, but results in encoded files about 1/8th smaller.
It used to be common practice for sites hosting Macintosh files to have two small Stuffit archives for test downloads, one in MacBinary and one in BinHex. First, download the smaller version and if it decoded and unstuffed OK you could download that format and save on your data and/or logon time limits. If it corrupted you had to try the larger, 7 bit version. If that corrupted too, then somewhere between you and the file host was some hardware that just didn't like Macintosh files.
Fortunately all the creaky old 7 bit systems are (should be!) long gone from the internet.
Topic: is it possible to fix destroyed resource forks? (Read 10437 times)