>Number:         16401
>Category:       kern
>Synopsis:       filesystem corrupt after 'rm' with msdosfs on vnd
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Apr 18 09:51:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Klaus Heinz
>Release:        NetBSD 1.5.2
>Organization:
none
>Environment:
System: NetBSD silence.homedns.org 1.5.2 NetBSD 1.5.2 (SILENCE) #5: Sun Mar
24 01:45:43 MET 2002 root@silence.homedns.org:/var/tmp2/src-1.5.2/sys/arch/
i386/compile/SILENCE i386

>Description:
	Using fsck_msdos and newfs_msdos on a vnd device does not
	work correctly. After some simple operations on the created
	filesystem, like 'rm', the filesystem is corrupted. The errors
	fsck reports are not always for the same files or in the same
	phases of the check.
	Doing the same on /dev/fd0b works for me.

	There seems to be a MACHINE- or MACHINE_ARCH-specific problem, because
	to my surprise this worked flawlessly both on NetBSD/Amiga 1.5.2
	and 1.5ZC (sources from 2002-04-16). I don't have -current on i386
	to test it.

>How-To-Repeat:
	Use this little script as user 'root':

	  #!/bin/sh
	  dd if=/dev/zero of=/var/tmp/img.vnd bs=512x18x2 count=80
	  newfs_msdos -f 1440 /var/tmp/img.vnd
	  vnconfig vnd0 /var/tmp/img.vnd 512/18/2/80
	  fsck_msdos -y /dev/rvnd0a
	  mount_msdos /dev/vnd0a /mnt
	  for i in 0 1 2 3 4 5 6 7 8 9 a b c d e f g h i j;
	  do echo test > /mnt/$i.txt;
	  done
	  rm /mnt/[4-5].txt /mnt/[d-g].txt
	  umount /mnt
	  fsck_msdos -y /dev/rvnd0a
	  vnconfig -u vnd0
	

	Output on NetBSD/i386 1.5.2:

	  # sh /var/tmp/msdos.sh
	  80+0 records in
	  80+0 records out
	  1474560 bytes transferred in 1 secs (1474560 bytes/sec)
	  ** /dev/rvnd0a
	  ** Phase 1 - Read and Compare FATs
	  ** Phase 2 - Check Cluster Chains
	  ** Phase 3 - Checking Directories
	  ** Phase 4 - Checking for Lost Files
	  1 files, 1423 free (2847 clusters)
	  ** /dev/rvnd0a
	  ** Phase 1 - Read and Compare FATs
	  Cluster 120 is marked free in FAT 0, as EOF in FAT 1
	  use FAT 0's entry? yes
	  Cluster 325 is marked free in FAT 0, as EOF in FAT 1
	  use FAT 0's entry? yes
	  Cluster 517 is marked free in FAT 0, as EOF in FAT 1
	  use FAT 0's entry? yes
	  Cluster 684 is marked free in FAT 0, as EOF in FAT 1
	  use FAT 0's entry? yes
	  Cluster 798 is marked free in FAT 0, as EOF in FAT 1
	  use FAT 0's entry? yes
	  Cluster 904 is marked free in FAT 0, as EOF in FAT 1
	  use FAT 0's entry? yes
	  Cluster 965 is marked free in FAT 0, as EOF in FAT 1
	  use FAT 0's entry? yes
	  Cluster 1012 is marked free in FAT 0, as EOF in FAT 1
	  use FAT 0's entry? yes
	  ** Phase 2 - Check Cluster Chains
	  ** Phase 3 - Checking Directories
	  /0.TXT starts with free cluster
	  Truncate? yes
	  /2.TXT starts with free cluster
	  Truncate? yes
	  /3.TXT starts with free cluster
	  Truncate? yes
	  /7.TXT starts with free cluster
	  Truncate? yes
	  /8.TXT starts with free cluster
	  Truncate? yes
	  /H.TXT starts with free cluster
	  Truncate? yes
	  /I.TXT starts with free cluster
	  Truncate? yes
	  /J.TXT starts with free cluster
	  Truncate? yes
	  ** Phase 4 - Checking for Lost Files
	  Update FATs? yes
	  Unable to write FAT (Read-only file system)
	  ***** FILE SYSTEM WAS MODIFIED *****

>Fix:
	none
>Release-Note:
>Audit-Trail:
>Unformatted: