From owner-freebsd-hackers Wed Aug 14 0:30:13 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D3A637B400 for ; Wed, 14 Aug 2002 00:30:04 -0700 (PDT) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2EEC43E4A for ; Wed, 14 Aug 2002 00:30:03 -0700 (PDT) (envelope-from hiten@angelica.unixdaemons.com) Received: from angelica.unixdaemons.com (hiten@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.5/8.12.1) with ESMTP id g7E7TuWr016702; Wed, 14 Aug 2002 03:29:56 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host hiten@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from hiten@localhost) by angelica.unixdaemons.com (8.12.5/8.12.1/Submit) id g7E7TtYI016701; Wed, 14 Aug 2002 03:29:55 -0400 (EDT) (envelope-from hiten) Date: Wed, 14 Aug 2002 03:29:55 -0400 From: Hiten Pandya To: freebsd-hackers@FreeBSD.org Cc: hiten@uk.FreeBSD.org Subject: Fixing issues with the MSDOSFS code. [w/ PATCH(es)] Message-ID: <20020814032955.A16015@angelica.unixdaemons.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Operating-System: FreeBSD i386 X-Public-Key: http://www.pittgoth.com/~hiten/pubkey.asc X-URL: http://www.unixdaemons.com/~hiten X-PGP: http://pgp.mit.edu:11371/pks/lookup?search=Hiten+Pandya&op=index Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello all. OK. I am going to get straight to the point. I was going through the PR database yesterday, and I saw that there are three PRs submitted on one same MSDOSFS issue. As we know, that there is no MSDOSFS maintainer; I have taken the courage to gather the patches, which, have know to work, and are still applicable to date. Below is my research: :-) I am submitting this, in the hopes, that a committer will pick them up, commit them, and put the PRs it affects into 'feedback' state. Thanking in advance. Regards. P.S. Findings attached with this mail. -- Hiten Pandya http://www.unixdaemons.com/~hiten hiten@unixdaemons.com, hiten@uk.FreeBSD.org, hiten@xMach.org PGP: http://pgp.mit.edu:11371/pks/lookup?search=Hiten+Pandya&op=index --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="msdos_critical.patch" The following patch fixes a number of issues within the FreeBSD MSDOS File System code. Delta one: ---------- Author: Semen Ustimenko The problem as submitted by the author (kern/24393) is: There are sometimes a FAT filesystems not handled correctly by msdosfs driver, but handled by mtools and other OSes. The problem is that msdosfs assume . entry in directory have cluster number set to real directory cluster number. But sometimes cluster number for . entry is set to 0, and msdosfs behaves wrong with such filesystems. Index: msdosfs_denode.c =================================================================== RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_denode.c,v retrieving revision 1.62 diff -u -r1.62 msdosfs_denode.c --- msdosfs_denode.c 2002/08/04 10:29:26 1.62 +++ msdosfs_denode.c 2002/08/14 00:09:19 @@ -356,6 +356,17 @@ */ u_long size; + /* + * XXX Sometimes, these arrives that . entry have cluster + * number 0, when it shouldn't. Use real cluster number + * instead of what is written in directory entry. + */ + if ((diroffset == 0) && (ldep->de_StartCluster != dirclust)) { + printf("deget(): . entry at clust %ld != %ld\n", + dirclust, ldep->de_StartCluster); + ldep->de_StartCluster = dirclust; + } + nvp->v_type = VDIR; if (ldep->de_StartCluster != MSDOSFSROOT) { error = pcbmap(ldep, 0xffff, 0, &size, 0); Delta two: ---------- Author: Jiangyi Liu Check against: NetBSD MSDOS-FS (they have similar fix) Problem: This delta fixes a bunch of problems, from fsck_msdosfs related problems, to >2GB hard drives; and last but not least, letting an msdosfs extended partition (massive ones) live peacefully. The following PRs are closable by applying this patch: - i386/28536 - misc/30168 - kern/32256 (hopefully) - kern/29121 (hopefully) Index: msdosfs_vfsops.c =================================================================== RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_vfsops.c,v retrieving revision 1.91 diff -u -r1.91 msdosfs_vfsops.c --- msdosfs_vfsops.c 2002/08/13 10:05:46 1.91 +++ msdosfs_vfsops.c 2002/08/14 00:31:16 @@ -543,8 +543,14 @@ } /* - * Check and validate (or perhaps invalidate?) the fsinfo structure? XXX + * Check and validate (or perhaps invalidate?) the fsinfo structure? */ + if (pmp->pm_fsinfo && pmp->pm_nxtfree > pmp->pm_maxcluster) { + printf("Next free cluster in FSInfo (%u) exceeds maxcluster (%u)\n", + pmp->pm_nxtfree, pmp->pm_maxcluster); + error = EINVAL; + goto error_exit; + } /* * Allocate memory for the bitmap of allocated clusters, and then --IS0zKkzwUGydFO0o-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message