All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: linux-fsdevel@vger.kernel.org
Subject: Re: clean unmount?
Date: 12 Mar 2003 20:40:38 -0800	[thread overview]
Message-ID: <b4p246$6j8$1@cesium.transmeta.com> (raw)
In-Reply-To: 20030310234800.GA4357@win.tue.nl

Followup to:  <20030310234800.GA4357@win.tue.nl>
By author:    Andries Brouwer <aebr@win.tue.nl>
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.
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> 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

  reply	other threads:[~2003-03-13  4:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-07  5:26 clean unmount? anil  vijarnia
2003-03-10 23:12 ` Bryan Henderson
2003-03-10 23:23   ` Matthew Wilcox
2003-03-10 23:48     ` Andries Brouwer
2003-03-13  4:40       ` H. Peter Anvin [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-03-07  5:24 anil  vijarnia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='b4p246$6j8$1@cesium.transmeta.com' \
    --to=hpa@zytor.com \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.