-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
Do StuffIt 5.5 archives encode the resource fork safely for transfer to a non-Mac ?
- Thread starter MrFahrenheit
- Start date
Indeed it is, it was just the easiest example I had on hand. They all work virtually the same, however.
My question is: does dd have a front end? There's nothing that I abhor more than a command line.
Would a script do?
. Definitely not fancy like the rest of you guys.
That's not a bad idea....I'd definitely give that a try.
For those of you coming across this thread, Protocol 7 on Macintosh Garden has written some scripts for macOS and Mac OS X, utilizing 'dd', to facilitate the proper extraction of CDs and DVDs to proper ISO images, and uploaded them here:
And we've done a fair bit of testing and feedback to ensure those scripts cover the edge cases. I have yet to find an optical disc where the current version of the scripts fail to do the correct thing.
Doesn't regular dd do that just fine?
I believe the scripts are made for those who find 'dd' too daunting or difficult to use.
The instructions for the scripts reads:
That seems fairly easy.
Also, it was disscovered when making the script that not all versions of dd are created equal. So the script does some extra checking now to make sure the images are generated correctly whether you're running OS X 10.2 or macOS 26.
There is a version of dd that doesn’t do the only thing dd is designed to do?
Not all versions have the same handling of default sector sizes or header data; They’ll all get you what you want in the end (an image of the disc’s contents), but do you know how to enforce the reading of gap data on all versions of dd?
Perhaps there is a misunderstanding of what dd does here, which I suppose is not out of line with this entire thread.
For those who don't know -- dd (data definition/definer) is a general purpose file read/write tool that can pipe to/from various interfaces including sockets, block devices and text streams. This means it can leverage existing filesystem drivers or serial read/write a hardware device, and if provided the correct parameters, can target sections of structured data within a defined data stream. It's strength is in the ability to do in-line data conversion, so you can use it to transform data from one data structure to another. It was originally designed to convert data between little endian and big endian formats.
The problem in the case of OS X / macOS is that the drivers and other OS-level tools available over its interface have changed over the years, both in what's available, and in how the APIs are exposed to dd. As a result, while dd is extremely flexible, the exact commands you need to use to accomplish the same task on different OSes/version can change.
So yes -- you can always "use dd" to image any device. But for people who don't understand what's being presented to the tool and how, and what data may not be captured/correctly transformed based on the interfaces available, having a script that does that work for you is useful, even if all it does is limits the tool to the basic "safe" command flags that have the same functionality across OS versions.
I too would like some documentation of why DU doesn't work, as well as what has changed to make dd not work. But I wasn't able to find any at the link, and none was forthcoming here. The script is just magic I guess.
Similar threads
