[EMAIL PROTECTED] (Bryan Henderson) wrote: ... >>Can you give an example showing why it'd be better to have this >>functionality in cp than in dd? > > Dd is a low level copy tool. It can't do things such as preserve > timestamps and permissions and copy a whole directory tree. Also, I > think the idea of recovering a bad block by reading the good parts in > smaller chunks is a little too high level for dd. I think the dd user > means to prescribe an actual sequence of read and write system calls > and doesn't want the program exercising any intelligence.
What is your motivation? Do you have so many corrupted files that it's important to have the recovery tool recurse and preserve timestamps and permissions? dd already has options for controlling both input and output block size as well as one for changing how errors are handled. The argument about dd being limited to the user-specified i/o block sizes makes sense for devices that mandate a particular block size, but for regular files (given a new option), there's no need to let that limit us. In any case, I would like to avoid converting cp into a forensic analysis tool. However, if enough people pipe up, saying this would be nice or it would have saved them some time, we can look harder at the prospect. Bear in mind that there are some dd patches in the pipeline. Here's one from Paul Eggert: http://mail.gnu.org/archive/html/bug-coreutils/2003-10/msg00071.html Jim _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
