Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 4814 - IDE/floppy support for ATAPI zip drive compromises data
IDE/floppy support for ATAPI zip drive compromises data
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Cristian Gafton
Depends On:
  Show dependency treegraph
Reported: 1999-08-31 19:09 EDT by craigk
Modified: 2008-08-01 12:22 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description craigk 1999-08-31 19:09:06 EDT
As distributed the Redhat 6.0 kernel with all redhat updates
released through 30Aug99 does not function with an Iomega
internal ATAPI zip drive.

Symptoms: drive can be mounted, single files can be read and
written.  When large numbers of files are copied "cp -r" to
a vfat formated disk, the directory structure below the top
couple levels is completely unreadable.  After this has
occured it is impossible to deleted the affected directory
tree.  Since the integrety of the data cannot be relyed
upon, the drive is essentially useless.  Since the drive
appears to work, this problem can easily cause serious loss
of data.

Work around:  I found that if the kernel is rebuilt with
CONFIG_CHR_DEV_SG=y (not verified as necessary)
then the zip drive functions well.  This apparently forces
the zip drive to be accessed via a SCSI emulation.

Naive suggestion: Build the default RH kernel with the
listed changes.  This also provides zip eject
functionality.  See "Running an ATAPI Zip Drive" by Steve

Further configuration and hardware information can be
supplied upon request.
Comment 1 Preston Brown 1999-09-01 10:09:59 EDT
we should have a kernel errata shortly that addresses this issue.

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