Messages in this thread | | | Date | Wed, 15 Mar 2000 10:19:53 +0000 (GMT) | From | James Sutherland <> | Subject | Re: [PATCH] zip drives |
| |
On Wed, 15 Mar 2000 Andries.Brouwer@cwi.nl wrote:
> Gadi Oxman writes: > > > Another point to add is that some (newer?) ZIP drives have a jumper > > on them which enables some cheat mode for MSDOS which actually hides > > some sectors from the device driver. That is, block 0 on the drive > > actually moves along with the partition table, and perhaps also the > > reported capacity. > > Yes, very good! [It wouldnt be the PC disk drive industry > if there weren't some fake and double-fake involved..] > That explains all reports seen so far concerning size, > geometry, partition table and "FAT bread failed" stuff. > > Yesterdays description must be modified: > > 100MB disks have a capacity of 100663296 bytes, i.e., 196608 sectors > > and the 100646912 bytes (196576 sectors) commonly seen is because > the first 32 sectors are hidden. > > The hiding is done on some models, not on early models > and not on the very latest either, and that explains why > people report that a disk that is fine on one machine > contains garbage on another, and when written on the other > looks like garbage on the first again. > > The hiding removes the first track including the MBR with > partition table. This explains how it can happen that the > same disk has to be mounted as /dev/sda on one machine > and as /dev/sda4 on another. > > I'll put this info on some web page. > > Maybe we should teach the kernel some of this stuff > so that a poor innocent user doesnt have to struggle. > [Detailed proposals for desired kernel behaviour are welcome.]
Load first sector. Is it an MBR/partition table, or a boot sector? If the former, add an offset of 32 sectors to all subsequent accesses. This way, we get consistent behaviour from both types of drive. You then always mount /dev/sda (or whatever).
(Alternatively, if there is some way of "unhiding" the first 32 sectors reliably, we should do that - is it possible??)
James.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |