|
|
|
|
| Welcome, Guest | Home | Search | Login | Register | |
| Author | Storing (disk) images on foreign file systems (Read 53 times) | ||||||
|
eelco
32 MB  Posts: 44 System 7 Newcomer! |
on: April 14, 2026, 23:34
Hello everyone! A situation arose today that leads me to this question. Short version: I powered up my Performa 630CD and found it A) still works and B) still had an original install on it. Wanting to capitalize on this opportunity, I created an image using Disk Copy 6.3.3 to a ZIP disk with the intention to store it on my NAS. I am well aware of the resource fork situation regarding files stored on HFS(+) volumes and how storing them on almost any other file system turns the resource fork into chop sticks. For good measure I used DropStuff to create a self-extracting archive along with a BinHex version of said archive and stored both along with the original image on the NAS (Synology DSM, btrfs). After uploading them, I downloaded all three again and alle three are fine. Does a Disk Copy image self-contain its resource fork? I.e. can a Disk Copy image be stored on any file system and still be fine? |
||||||
|
68040
|
512 MB Posts: 971 68k - thy kingdom come, thy will be done !
Reply #1 on: April 14, 2026, 23:52
|
Hello eelco, you have to distinguish between resource fork that contain actual data important for a program's function (like text strings for menus or image resources) and simple type/creator associations. For a disk copy image you'll only be missing the later one, which can easily be fixed with a variety of tools form the garden. As far as the first variety is concerned: I had very good experiences with netatalk shares. That's a Linux implementation of AppleTalk network shares, which stores the resource info in AppleDouble format on the target disk. There is also a Samba extension for MacOS 68k on the Garden (Dave), but I found that tends to drop the connection to the network store rather randomly. Well, your mileage may vary. But in any case, it does not use the Apple Double format to store those resource forks. Instead it relies on its own proprietary implementation. Not sure why they did that, but it makes their file sets incompatible with netatalk/AppleTalk shares. So you have to decide which one to chose and stick with it. Last not least, there are FTP servers (e.g. Rumpus and WebSTAR) which automate the process of wrapping your MacOS files in .bin or .hqx packages. If you are able to connect an FTP client to your Mac from the outside, you can in this way download an entire directory tree, with each file stored externally as a bin/hxq package.
Last Edit: April 14, 2026, 23:57 by 68040
|
|
Pages: [1]
|
| ||
|
© 2021 System7Today.com. |
