NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

kern/59924: NetBSD improperly does not update FAT0 on FAT12 MSDOS filesystem



>Number:         59924
>Category:       kern
>Synopsis:       when files are created/removed from MSDOS FAT12 filesystem, FAT0 is not updated
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jan 16 22:45:00 +0000 2026
>Originator:     mac%culver.net@localhost
>Release:        NetBSD 10.1
>Organization:
	
>Environment:
	
	
System: NetBSD SS.Culver.Net 10.1 NetBSD 10.1 (MIKE-$Revision: 2025-Dec-27 $) #1: Sun Dec 28 19:39:48 UTC 2025 mac%SS.Culver.Net@localhost:/usr/src/sys/arch/amd64/compile/MIKE amd64
Architecture: x86_64
Machine: amd64
"MIKE" is just a rename of GENERIC kernel with no changes.
>Description:
	Doing any FAT12 operation that requires updating the FAT fails due to FAT0 not being updated.
        Since floppies using FAT12 are still used as an interchange medium, I marked the Severity as "serious".
>How-To-Repeat:

        # dmesg | tail -6
        [ 1643401.856636] umass3 at uhub1 port 2 configuration 1 interface 0
        [ 1643401.856636] umass3: TEACV0.0 (0x0644) TEACV0.0 (0x0000), rev 1.10/2.00, addr 19
        [ 1643401.856636] umass3: using UFI over CBI with CCI
        [ 1643401.856636] atapibus0 at umass3: 2 targets
        [ 1643401.876637] sd3 at atapibus0 drive 0: <TEAC, USB UF000x, 0.00> disk removable
        [ 1643402.706681] sd3: 1440 KB, 80 cyl, 2 head, 18 sec, 512 bytes/sect x 2880 sectors

        # newfs_msdos /dev/rsd3
        /dev/rsd3: 2840 sectors in 355 FAT12 clusters (4096 bytes/cluster)

        MBR type: 1 bps=512 spc=8 res=1 nft=2 rde=512 sec=2880 mid=0xf0 spf=2 spt=18 hds=2 hid=0

        # fsck_msdos /dev/rsd3
        ** /dev/rsd3
        ** Phase 1 - Read and Compare FATs
        ** Phase 2 - Check Cluster Chains
        ** Phase 3 - Checking Directories
        ** Phase 4 - Checking for Lost Files
        1 files, 1420 free (355 clusters)

        # mount_msdos /dev/sd3a /a

        # ls /a

        # ls -l /root/floppy/bytes.bin
        -rwxr-xr-x  1 root  wheel  1536 Jan  1  1970 /root/floppy/bytes.bin*

        # cp /root/floppy/bytes.bin /a

        # ls /a
        bytes.bin*

        # umount /a

        # fsck_msdos -n /dev/rsd3
        ** /dev/rsd3
        ** Phase 1 - Read and Compare FATs
        Cluster 144 is marked free in FAT 0, as EOF in FAT 1
        use FAT 0's entry? no
        use FAT 1's entry? no

        This is just the simplest manifestation of this error.  when reading or writing files, it gets really screwed up.

        I first discovered this by dd'ing this image http://culver.net/NetBSD/dd-msdos-fat12.img.xz
        onto a blank floppy; that is an exact construction of 1,474,650 bytes -- it consists of FAT0, FAT1,
        the 3 remaining sectors in Cylinder 0 coalesced into BYTES.BIN, and then 79 files, of the form
        CYL000XX.BIN where xx goes from 01 to 79, and each file fills a complete cylinder; and the value of
        the 18,432 bytes is the "xx"  e.g. CYL00065.BIN is filled with the character 'A'.

        This behavior can also be demonstrated using vnd:

        # ftp  http://culver.net/NetBSD/dd-msdos-fat12.img.xz

        # unxz dd-msdos-fat12.img.xz

        # ls -l dd-msdos-fat12.img
        -rw-r--r--  1 root  wheel  1,474,560 Dec 23 03:02 dd-msdos-fat12.img

       # md5 dd-msdos-fat12.img
        MD5 (dd-msdos-fat12.img) = 67cb3c500cf779b5db6cb704694c4a39

        # vnconfig -c vnd0 dd-msdos-fat12.img

        # mount_msdos /dev/vnd0a /mnt

        # ls /mnt
        bytes.bin*     cyl00010.bin*  cyl00020.bin*  cyl00030.bin*  cyl00040.bin*  cyl00050.bin*  cyl00060.bin*  cyl00070.bin*
        cyl00001.bin*  cyl00011.bin*  cyl00021.bin*  cyl00031.bin*  cyl00041.bin*  cyl00051.bin*  cyl00061.bin*  cyl00071.bin*
        cyl00002.bin*  cyl00012.bin*  cyl00022.bin*  cyl00032.bin*  cyl00042.bin*  cyl00052.bin*  cyl00062.bin*  cyl00072.bin*
        cyl00003.bin*  cyl00013.bin*  cyl00023.bin*  cyl00033.bin*  cyl00043.bin*  cyl00053.bin*  cyl00063.bin*  cyl00073.bin*
        cyl00004.bin*  cyl00014.bin*  cyl00024.bin*  cyl00034.bin*  cyl00044.bin*  cyl00054.bin*  cyl00064.bin*  cyl00074.bin*
        cyl00005.bin*  cyl00015.bin*  cyl00025.bin*  cyl00035.bin*  cyl00045.bin*  cyl00055.bin*  cyl00065.bin*  cyl00075.bin*
        cyl00006.bin*  cyl00016.bin*  cyl00026.bin*  cyl00036.bin*  cyl00046.bin*  cyl00056.bin*  cyl00066.bin*  cyl00076.bin*
        cyl00007.bin*  cyl00017.bin*  cyl00027.bin*  cyl00037.bin*  cyl00047.bin*  cyl00057.bin*  cyl00067.bin*  cyl00077.bin*
        cyl00008.bin*  cyl00018.bin*  cyl00028.bin*  cyl00038.bin*  cyl00048.bin*  cyl00058.bin*  cyl00068.bin*  cyl00078.bin*
        cyl00009.bin*  cyl00019.bin*  cyl00029.bin*  cyl00039.bin*  cyl00049.bin*  cyl00059.bin*  cyl00069.bin*  cyl00079.bin*

        # umount /mnt

        # fsck_msdos -n /dev/vnd0a
        ** /dev/vnd0a
        ** Phase 1 - Read and Compare FATs
        ** Phase 2 - Check Cluster Chains
        ** Phase 3 - Checking Directories
        ** Phase 4 - Checking for Lost Files
        81 files, 0 free (0 clusters)

        # mount_msdos /dev/vnd0a /mnt

        # rm /mnt/bytes.bin

        # umount /mnt

        # fsck_msdos -n /dev/vnd0a
        ** /dev/vnd0a
        ** Phase 1 - Read and Compare FATs
        Cluster 2 continues with cluster 3 in FAT 0, but is marked free in FAT 1
        Use continuation from FAT 0? no
        Use mark from FAT 1? no
        Cluster 3 continues with cluster 4 in FAT 0, but is marked free in FAT 1
        Use continuation from FAT 0? no
        Use mark from FAT 1? no
        Cluster 4 is marked as EOF in FAT 0, free in FAT 1
        use FAT 0's entry? no
        use FAT 1's entry? no


        The AIs have some ideas: https://gemini.google.com/share/2d8a6f3be51a

        "FAT #0 is located where NetBSD expects/guards the disklabel sector (sector 1).
         Since that sector is protected by default, updates to FAT0 donâ??t land,
         while FAT1 does -â?? producing the mismatch youâ??re seeing."

>Fix:
        

>Unformatted:
 	
 	


Home | Main Index | Thread Index | Old Index