From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: clean unmount? Date: 12 Mar 2003 20:40:38 -0800 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: References: <20030307052645.9851.qmail@webmail29.rediffmail.com> <20030310232322.GB21234@parcelfarce.linux.theplanet.co.uk> <20030310234800.GA4357@win.tue.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Return-path: Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id UAA18551 for ; Wed, 12 Mar 2003 20:40:52 -0800 Received: from palladium.transmeta.com (palladium.transmeta.com [10.0.0.117]) by deepthought.transmeta.com (8.11.6/8.11.6) with ESMTP id h2D4eda13930 for ; Wed, 12 Mar 2003 20:40:39 -0800 (PST) Received: (from mail@localhost) by palladium.transmeta.com (8.9.3/8.9.3) id UAA14343 for linux-fsdevel@vger.kernel.org; Wed, 12 Mar 2003 20:40:39 -0800 To: linux-fsdevel@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Followup to: <20030310234800.GA4357@win.tue.nl> By author: Andries Brouwer In newsgroup: linux.dev.fs.devel > > My docs say "high-order" instead of "low-order". > Are there people with a Windows system so that they can check? > > Andries > > http://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html#ss1.3.1 > The FAT spec claims it's the high bits, which makes sense because 0x..FF8 and 0x..FFF are all technically valid EOCs (in fact, Linux for a long time wrote 0x...FF8 instead of the correct 0x...FFF): For FAT16 and FAT32, the file system driver may use the high two bits of the FAT[1] entry for dirty volume flags (all other bits, are always left set to 1). Note that the bit location is different for FAT16 and FAT32, because they are the high 2 bits of the entry. For FAT16: ClnShutBitMask = 0x8000; HrdErrBitMask = 0x4000; For FAT32: ClnShutBitMask = 0x08000000; HrdErrBitMask = 0x04000000; Bit ClnShutBitMask If bit is 1, volume is clean . If bit is 0, volume is dirty . This indicates that the file system driver did not Dismount the volume properly the last time it had the volume mounted. It would be a good idea to run a Chkdsk/Scandisk disk repair utility on it, because it may be damaged. Bit HrdErrBitMask If this bit is 1, no disk read/write errors were encountered. If this bit is 0, the file system driver encountered a disk I/O error on the Volume the last time it was mounted, which is an indicator that some sectors may have gone bad on the volume. It would be a good idea to run a Chkdsk/Scandisk disk repair utility that does surface analysis on it to look for new bad sectors. -- at work, in private! "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64