Hi,

While I don't have a zip disk, I think I can guess the origin of your
problems.

> I had some trouble attempting to use fsck_msdos on a zip disk.  Since
> this was with a relatively old system (1.2G vintage), I didn't let it
> worry me.  But I did save a dd image of the disk.
> 
> Now, on a relatively recent system (built from sources supped
> 1998-04-23), I find the same problem, or at least the same symptom:
> 
> [Sparkle - root] 10> vnconfig /dev/rvnd0c /home/mouse/tmp/zip.dd
> [Sparkle - root] 11> fsck_msdos /dev/rvnd0c
> ** /dev/rvnd0c
> Invalid sector size: 8293[Sparkle - root] 12> 

This means that the first sector of your image, which is supposed to describe
the fat file system, doesn't make sense to fsck_msdos.

> Now, both sparkle and the 1.2Gish machine I mentioned above are SPARCs.
> Are the msdos filesystem tools supposed to work on SPARCs?  It occurs
> to me that they may not have been well tested on big-endian machines.

In fact, fsck_msdos was initially developped on a SPARC running SunOS :-).
(Ok, the real beginnings were done by Martin Husemann, and I don't know
what system he used for it, but when I took over, I first used a SPARC for it).

> Alternatively, there could be something else wrong.  The only clue I
> have that sounds to me as though it might possibly have anything to do
> with it is that someone who knows more about DOS boxen than I do said
> something about zip disks always having the filesystem on partition 4,
> and indeed on the Linux machine I eventually used dosfsck on to repair
> the filesystem, I used /dev/sda4, and on the SGI that we originally
> tried with, upon mounting it showed up with "partition=4".  So it
> occurs to me that maybe the fsdos tools don't know how to deal with
> partitioning, though I can't see how that can be when people regularly
> partition disks with msdos filesystems on them.  For what it's worth,

It's not a matter of the fsdos tools, as the partitioning is done somewhere
else.

> applying disklabel to the vnd produces a partition table showing only
> an a partition, covering the full 96 megabytes of the disk; using
> disklabel on the real zip disk on the 1.2Gish system produced similar
> output.  So perhaps there *isn't* a real partition table there and the
> "partition 4" thing is a software fiction.

DOS boxen have a Master Boot Record as the very first sector of any
hard disk (most likely this is also true for your zip disk).  This MBR
has a partition table of its own (which is of course quite different from
a NetBSD disklabel), which can hold up to four partitions.

Normally, in order to free up the space for this MBR, the whole first
track of the disk is reserved.  So the first partition on the disk will
normally start at the first sector on the second head on the first cylinder
of the disk.

Now on PCs NetBSD tries to be clever about this and will fake a NetBSD
disklabel on disks that don't have one.  This disklabel will have entries
describing the MBR partitions as e, f, g and h.  So you are able to use these
partition names to access the dos partitions.

But since you are using a SPARC, the disklabel reading routine isn't prepared
to interpret this MBR.  In order to access the correct part of the disk
you'd have to add a disklabel describing the part of the disk that is used
for the fat partition.  Alternatively you could dd the whole disk to a file
skipping the first track.

Finding the size of this first track might be a problem though.
If you don't know the size, try to dump the beginning of the disk.
Apart from the very first sector, the rest of the first track should be empty,
i.e. it probably contains all the same data, most likely all 0s.  So look
where some different data starts again, and that should be the start of the
fat partition.

> In case you can't tell, I'm confused and would appreciate any help
> anyone has to offer.  There is no immediate problem; mounting the disk
> on the Linux box has addressed the need of the moment.  But there is
> clearly something I don't understand going on here, and if nothing else
> there's a functional sense in which the msdos tools don't work, though
> admittedly I could be using them wrong.

Hope the above clarifies things a bit for you.  If you have any additional
questions, feel free to ask.

Ciao,
Wolfgang
-- 
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800