I've just been speaking to Drew Fahey the author of Helix. The Linux side of the Helix distro has dcfldd and it is used in the GUI environment called Adepto. He is going to do his own testing and will comment in due course.
In the meantime users of Helix on the Linux side can use ddrescue with the -d flag set as this is on the disk too and Barry's research and some testing here seems to indicate the same problems do not appear. The windows tools are not affected apart from the stated issues with FAU-dd.
Obviously this is not a specific Helix problem but does affect users wanting to use Adepto/DCFLDD and ensure data integrity. The release of Helix 2.0, to be called Helix Pro will be with us by the end of the summer and these problems will have been addressed.
Nick Furneaux
Obviously this is not a specific Helix problem but does affect users wanting to use Adepto/DCFLDD and ensure data integrity.
Again, I'd like to point out that this does not affect "data integrity" when imaging with dd based tools.
If you want to continue using Adepto/DCFLDD/dd/whatever, then do so. I would advise that you simply drop the "conv=noerror,sync" option. That way the acquisition will fail on errors, and be verbal about it, so you can decide to move on to a more suitable tool…Or use /dev/raw with "conv=noerror,sync", or use ddrescue with -d from the start.
Again, from my perspective, all this "research" did was highlight the fact that "conv=noerror,sync" is BAD. That's all. If you need to use that option, you are using the wrong tool.
Thats a fair point Barry. I think our concern is that Adepto defaults to the noerror argument and users should at least be aware of the question mark. I agree that this shouldnt mean dd is removed from a linux toolkit but the issue should be made clear to the community as you and others are eloquently doing.
Thanks for your comment.
Nick
… our concern is that Adepto defaults to the noerror argument …
Ahhh…see, I didn't know that. Never used Adepto.
Well then…carry on! 8)
Barry, question for you.
You mention in your post using ddrescue with the-d flag set and in parenthesis say 'not dd_rescue'. dd_rescue also has a O_DIRECT -d flag, have you tested that tool yet or were you just differentiating? I'll give it a try but am on holiday until the weekend and have limited capabilities in a house in central France!
Sorry for bothering you on the point.
Nick
…dd_rescue also has a O_DIRECT -d flag, have you tested that tool yet or were you just differentiating?
Just differentiating. I'd guess the results would be the same, but I have not tested dd_rescue (and likely won't, for my purposes).
Thats great thanks. Helix has dd_rescue but not ddrescue, I'll do some testing in the next few weeks and repost.
The problem on the Windows side with the original FAU-dd with it skipping 4096b is an issue on Helix as Georges later version does not support memory acquisition and many people use Helix for that purpose. Drew is aware of it and we should see that resolved in due course. Of course the Windows side has FTK installed too which helps.
Thanks again
As Barry has noted, there is a difference (big) between dd_rescue and ddrescue. For I/O problematic drives you will want to use ddrescue by GNU. The error handling is superb with the RAW device.
Cheers!
farmerdude
http//
http//
I agree, in fact I've been able to do more testing now and I've found that dd_rescue will often produce a null size file when the -d flag is set. ddrescue is much better.
Nick
It appears that dc3dd supports direct I/O via iflag=direct (which uses O_DIRECT).
I'll do some testing and report back, but this should solve the problem. It should be similar to GNU ddrescue with the -d option, but you also get the built-in hashing (and other features), which ddrescue does not have.
-Steve