In article <rmislk7qc5t.fsf@fnord.ir.bbn.com>,
Greg Troxel  <gdt@ir.bbn.com> wrote:
>-=-=-=-=-=-
>
>
>I've been mounting CF cards with MS-DOS filesystems for a long time to
>use digital cameras.  Recently a friend got a new camera and a new
>Sandisk 4 GB Extreme III CF.  She put the card in the camera, did a
>format (since apparently the CF doesn't have the DCIM structure to
>start with), shot a bunch of pictures, and was able to mount the CF on
>windows without problems.  On her NetBSD machine (i386/3-stable),
>mount failed with EINVAL.
>
>On inspection, I found two problems with NetBSD's msdosfs
>support.
>
>1) fsck_msdos complains about primary/alternate superblock mismatches.
>
>cmp -l between block 0 and 6 (alternate) shows:
>
>    73 111 117
>    74 113  40
>    75 117 116
>    76 116 101
>    77  40 115
>    78 104 105
>    79  62  40
>    80  60  40
>    81  60  40
>
>This is "IKON D200" and "O NAME   ".  Fairly clearly, the camera wrote
>the primary superblock and didn't update the name in the backup.
>
>The mount vfsop does not check the backup superblock, so this is not
>an actual problem.  But fsck_msdos should make this be a warning, and
>perhaps check the creator name separately.
>
>2) msdosfs's mount vfsop insists on bootsig2 and bootsig3 (bytes
>   252-253) being 0 for FAT32.  But, sandisk ships cards without 0, a
>   good quality camera formats without changing these, and windows
>   doesn't care.  So I'd say that this isn't part of the real spec.
>
>Block 0 of the card was:
>
>0000000  353 376 220   M   S   D   O   S   5   .   0  \0 002   @      \0
>0000020  002  \0  \0  \0  \0 370  \0  \0   ?  \0 020  \0   ?  \0  \0  \0
>0000040  301 017   z  \0 321 003  \0  \0  \0  \0  \0  \0 002  \0  \0  \0
>0000060  001  \0 006  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
>0000100  200  \0   )  \0  \0  \0  \0   N   I   K   O   N       D   2   0
>0000120    0       F   A   T   3   2             220 220 220 220 220 220
>0000140  220 220 220 220 220 220 220 220 220 220 220 220 220 220 220 220
>*
>0000760  220 220 220 220 220 220 220 220 220 220 220 220 220 220   U 252
>0001000
>
>I dd'd this to a file, changed bytes 252 and 253 to zero, and dd'd
>back to the CF.  I was then able to mount the card.
>
>
>I suggested to my friend that after she had the bits off, that she
>format the card under Windows XP (assuming that's the working
>definition of msdosfs since there are no real specs), and then in the
>camera.  This resulted a card that works on Windows but not on NetBSD.
>
>for reference, this is from sys/fs/msdosfs/bootsect.h:
>
>struct bootsector710 {
>	u_int8_t	bsJump[3];		/* jump inst E9xxxx or EBxx90 */
>	int8_t		bsOEMName[8];		/* OEM name and version */
>	int8_t		bsBPB[53];		/* BIOS parameter block */
>	int8_t		bsExt[26];		/* Bootsector Extension */
>	int8_t		bsBootCode[418];	/* pad so structure is 512b */
>	u_int8_t	bsBootSectSig2;		/* 2 & 3 are only defined for FAT32? */
>	u_int8_t	bsBootSectSig3;
>	u_int8_t	bsBootSectSig0;
>	u_int8_t	bsBootSectSig1;
>#define	BOOTSIG0	0x55
>#define	BOOTSIG1	0xaa
>#define	BOOTSIG2	0
>#define	BOOTSIG3	0
>};
>
>I'd like to do the following:
>
>  1) modify msdosfs_vfsops.c to not check sig2/sig3, since it seems
>     that isn't really a rule.

That is ok I guess.

>  2) modify fsck_msdos to not complain about the creator name being
>     different in the backup superblock, since apparently that isn't
>     really a rule either.

This should not be compiled in by default (DPRINTF())..

>any objections?

Fix the whitespace in the for loop.

christos