bug-fileutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ANNOUNCE] GNU fileutils 4.1


From: Paul Eggert
Subject: Re: [ANNOUNCE] GNU fileutils 4.1
Date: Thu, 24 May 2001 08:19:09 -0700 (PDT)

> Date: Wed, 23 May 2001 18:15:08 -0700 (PDT)
> From: Dave Dittrich <address@hidden>

> > 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?
> 
> md5sum just reads stdin and checksums it.  It doesn't have any of the
> other features of dd, like byte swapping, alternate output blocking
> for efficiently filling streaming media buffers, etc.

But if you add one simple options to md5sum to control the location of
the checksum output, and to make a copy to standard output, you can
get all the above.  For example, you could do the following:

   dd if=/big/input/device ibs=whatever |
   md5sum -C checksum.txt |
   dd of=/big/output/device obs=whatever

where '-C FOO' means "put a copy of the checksums in FOO and output a
copy of the input to standard output".

> Because of the acceptability requirement for the courts, it is most
> advantageous to get this into the official dd release, rather than a
> separate program that may not be widely used.

But GNU md5sum is just as widely used as GNU dd.  And it seems to me
that a simpler program like GNU md5sum, dedicated entirely to the
problem of computing checksums accurately, is more likely to convince
a court than a more complicated program like GNU dd-with-checksums
would.

(My own beef with md5sum and shasum is that the checksum algorithm
should not be part of the program name; there should just be one
checksum program, with different algorithms as options.  But that's a
different story...)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]