Re: dd / netcat / md5sums: hashes do not match

From: Casper H.S. Dik (Casper.Dik_at_Sun.COM)
Date: 09/18/03

  • Next message: Mark Hittinger: "Re: dd / netcat / md5sums: hashes do not match" 
    Date: 18 Sep 2003 14:19:25 GMT

    solana_nexus@hotmail.com (solana) writes:

    >B# nc -l -p 6789 | dd of=./hda1.img bs=512 conv=noerror,sync
    >A# dd if=/dev/hda1 bs=512 conv=noerror,sync | nc <B's IP> 6789

    I wouldn't use "sync" because sync causes blocks to be
    padded with NULLs; this is certain to corrupt
    the file.

    >Still gives different md5sum results.

    >btw. the 'records' output also differs.

    >On A:
    >3084416+0 records in
    >3084416+0 records out

    >On B (the receiver):
    >2323232+1140752 records in
    >3463984+0 records out

    Each of the incomplete reads (1140752) will be zero filled and that's
    why there's more output.

    Since it's over the net you probably get two 512 byte blocks and then
    some each packet which accounts for the 2:1 complete/incomplete ratio.

    Perhaps you'd like to specify "obs" so that just the output
    is blocked and aggregated.

    Casper

    >however, A is a live system. Cant unmount hda1 since it happens to be
    >the / part. cant boot into single user since I then wouldnt have
    >network conn, i.e. not be able to transfer the file.

    Ah, in that case the checksums will never match but as long as the
    fs is mostly idle (kill syslog and other sources of logs); you
    should get a near perfect copy; nothing fsck can't fix.

    Casper 

    -- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
  • Next message: Mark Hittinger: "Re: dd / netcat / md5sums: hashes do not match"
    • Quantcast