Bug 74938 - Mistake in "Collecting an Evidential Image"
Summary: Mistake in "Collecting an Evidential Image"
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rhl-sg
Version: 8.0
Hardware: noarch
OS: Linux
medium
medium
Target Milestone: ---
Assignee: John Ha
QA Contact: Tammy Fox
URL: http://www.redhat.com/docs/manuals/li...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-10-02 21:59 UTC by Paul W. Frields
Modified: 2014-08-04 22:14 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-10-07 18:26:03 UTC
Embargoed:


Attachments (Terms of Use)

Description Paul W. Frields 2002-10-02 21:59:04 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830

Description of problem:
The exemplar dd command given should include the conv=sync tag as well as
conv=noerror.  In the event an error is encountered on the input medium, the
"sync" tag prevents the output from skewing offsets.  For instance, if a bad
sector occurs on the source medium, the user will lose data, potentially up to
the block size used by dd (in the exemplar, 1 KB).  The sync tag will ensure
that the erratic block is padded with 0x00 bytes on the output, so that
disklabels and volume structures (be they superblocks, inode or FAT tables, and
data areas) are aligned properly for recovery efforts.

Version-Release number of selected component (if applicable):
rhl-sg(EN)-8.0-HTML-RHI (2002-08-30T11:29-0400)

How reproducible:
Always

Steps to Reproduce:
1. Read manual.
2. Attempt to dd a source medium with bad blocks, without using "sync" parameter
for "conv=" option.


Actual Results:  The destination file is a smaller size, and data loss makes
certain file or recovery procedures impossible (or at least VERY difficult).  If
destination is a device, bad things also happen.  :-)

Expected Results:  Although some data loss must occur in the case cited above,
unless that loss occurs in a primary disk structure like the disklabel, or a
unified structure like the NTFS MFT, most file operations should be possible
with minimal effects.  Some files may be affected by the error but most should
be addressable by normal methods.

Additional info:

I have a specialized background in this area.

Comment 1 John Ha 2002-10-02 22:52:16 UTC
Thank you very much for your suggestion. I am investigating this issue and will
get back to you as soon as possible.

Thanks again.

Comment 2 John Ha 2002-10-07 18:25:57 UTC
Thank you for your patience. It has been determined that your suggestion is
correct and the example command will be modified to add the 'conv=noerror,sync'
argument by the next version of the Security Guide.

Thanks again for your input. Feedback like yours will make the Security Guide a
better resource for all readers.


Note You need to log in before you can comment on or make changes to this bug.