Originally Posted By: Virtual1
I think dd behaves differently than you are expecting. If it hits an error that stumps it (hangs dd, either temporarily or permanently) then ctrl-c won't save you. It'll be blocking in the kernel until it finishes the block it was reading. THEN ctrl-c may stop it. But it's been my experience that unless you're using a very small block size (512 etc) then you're in for an awful long wait, as each disc block (512) may take 1-2 minutes to pass. If your dd block size is 1mb, it could be 20 minutes or more before it releases with ctrl-c. Some block errors never complete and block until killed.

Yes, i would expect that. I mean, bad blocks can make just logging in or opening a Finder window take 20 minutes. Such pain is not an exclusive feature of Terminal or dd under those circumstances.

Originally Posted By: Virtual1
The reason to not use conv=noerror is that if it gets an error (that passes quickly, say one bad disk block in the entire dd block) then it will display the io error to console, but with conv=noerror, it WON'T STOP,

All good (for those who wanted that to happen).

Originally Posted By: Virtual1
and will NOT return an error code when dd finally finishes. This isn't usually how you want it to behave when looking for errors, unless you are trying to count how many you have. (I usually consider one to be more than enough!)

I think there's where our preferences differ. In your context (at a work place), you're mainly interested in strict PASS/FAIL type of analysis... so you can swiftly move on to what else needs doing. (i.e., probably tackle another broken machine that's been waiting for your attention).

We folks at home are focused on our sole problem machine (or device), and are more inclined to want to find more details about how badly the disk's condition was degraded... even if it takes a little time. And if it turns out to be a total of 1 or 2 bad blocks... then maybe a quick full erase [to remap] could make the disk last another day or 3, while we wait for FedEx to deliver the replacement. I remember my first one was a doozy... the main boot partition was hosed with hundreds of bad blocks. I was able to determine the count thanks to ditto -V, which i used to salvage what i could (by copying it off to an external). The copying ditto did took around 28 hours (and that was just the /Users folder, IIRC). Bad blocks are a bitch.



Originally Posted By: Virtual1
(fyi, dd pads unreadable blocks with zeros if you use conv=noerror)

True, but /dev/null won't mind in the least "bit". wink


Originally Posted By: Virtual1
Finder needs a nice contextual menu item for "create disk image" that would DMG a folder, or if it was a file, made a folder by the same name, put it in the folder, and DMG'd that. (or is there something like that available you know of?)

Yes, there is Compress in Finder's contextual menu. [it makes a zip archive.] We can actually tweak a few of its "features" which get saved into a com.apple.archiveutility.plist in our home library (so we're not monkeying with the system really).

One simple way to access those prefs is to create a symbolic link to it:
Code:
ln -s /System/Library/CoreServices/Archive\ Utility.app/Contents/Resources/Archives.prefPane ~/Library/PreferencePanes/

That command puts a symlink in our ~/Library/PreferencePanes/ folder, so when we open System Prefs, a new prefpane will appear there. See this article for more info (and pictures): New hidden PrefPanes in Leopard

Last edited by Hal Itosis; 01/19/10 05:56 AM.