Re: [ANNOUNCE] GNU fileutils 4.1

[Paul Eggert]

> Date: Wed, 23 May 2001 14:24:04 -0700 (PDT)
> From: Dave Dittrich <address@hidden>

> > I'd like to see an
> > explanation of why this feature is needed in dd.  You can already do
> > something like the following to calculate checksums of part of your disks:
> >
> >   dd ibs=1024 if=/dev/hda1 count=1 | md5sum
> 
> Consider doing that for a 30GB drive before you copy each partition,
> then again after you copy them to disc/tape, and/or piping them over
> the network at the same time.  It can mean the difference between
> spending 2 hours imaging a system vs. 6 - 8 or more hours.  The
> greater the size of disc and slower the copy medium (e.g., 4mm DDS-1
> tape), the more time and trouble it is.

A nit: dd can only tell you the checksum for the file that it reads,
not for the file that it writes.  So you need to do something like the
above step anyway, for the last copy in your chain.

> Also I added the feature of generating an MD5 checksum for each block
> read at the same time as checksumming the entire stream.

OK, OK, you're starting to convince me.  :-)

I'm not sure, though, that dd is the right place for this; perhaps it
would be better to have a separate tool?  dd tends to suffer from the
kitchen-sink problem.  Maybe it's better to put this into md5sum
instead?

> I want to have a method of maintaining chain of custody and
> integrity throughout the process of imaging and file transfer, even
> in the face of bad media or one lost/damaged CD-ROM out of a set of N.

It seems to me that the most important part of your proposed change is
the documentation for it.  That will help to explain to users why the
change is important (as well as justify it to the maintainer).  The
documentation should address issues like how to checksum the output,
and also how to store the checksums safely (do you checksum the
checksums?  that sort of thing).  I don't think a treatise is needed
(though it would be nice), but a simple howto would be quite helpful.