All of lore.kernel.org
 help / color / mirror / Atom feed
From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: Helge Hafting <helgehaf@aitel.hist.no>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [Q] FAT driver enhancement
Date: Tue, 02 Apr 2002 22:27:52 +0900	[thread overview]
Message-ID: <87663acjs7.fsf@devron.myhome.or.jp> (raw)
In-Reply-To: <20020328135555.U6796-100000@snail.stack.nl> <871ye479sz.fsf@devron.myhome.or.jp> <3CA97B1A.13E6765D@aitel.hist.no>

Helge Hafting <helgehaf@aitel.hist.no> writes:

> OGAWA Hirofumi wrote:
> > 
> > Jos Hulzink <josh@stack.nl> writes:
> > 
> > > Hi,
> > >
> > > A while ago I initiated a thread about mounting a NTFS partition as FAT
> > > partition. The problem is that FAT partitions do not have a real
> > > fingerprint, so the FAT driver mounts almost anything.
> > >
> > > The current 2.5 driver only tests if some values in the bootsector are
> > > non-zero. IMHO, this is not strict enough. For example, the number of FATs
> > > is always 1 or 2 (anyone ever seen more ?). Besides, when there are two
> > > FATs, all entries in those FATs should be equal. If they are not, we deal
> > > with a non-FAT or broken FAT partition, and we should not mount.
> > >
> > > It's not a real fingerprint, but what are the chances all sectors of what
> > > we think is the FAT are equal on non-FAT filesystems ? Yes, when you just
> > > did a
> > >
> > > dd if=/dev/zero of=/dev/partition; mkfs.somefs /dev/partition
> > >
> > > there is a chance, but that's an empty filesystem. Data corruption isn't
> > > that bad on an empty disk. We know that a FAT is at the beginning of a
> > > partition and I assume that any other filesystem will fill up those first
> > > sectors very soon.
> > >
> > > Questions:
> > >
> > > 1) How do you think about the checking of the FAT tables ? It definitely
> > >    will slow down the mount.
> > 
> > Unfortunately if FAT table has bad sector, FAT tables may not be the
> > same.
> 
> And then you don't want to mount unless you know what you
> are doing.  And those knowing what they are doing can be bothered
> to use some kind of "force" option in this case.  Or perhaps an
> option that selects which FAT to trust.

I mean I/O error, not data damage.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

  reply	other threads:[~2002-04-02 13:28 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-28 13:25 [Q] FAT driver enhancement Jos Hulzink
2002-03-28 19:48 ` OGAWA Hirofumi
2002-04-02  9:34   ` Helge Hafting
2002-04-02 13:27     ` OGAWA Hirofumi [this message]
2002-04-02 22:13       ` Mike Fedyk
2002-04-03  7:07         ` Jens Axboe
2002-04-03 11:54         ` OGAWA Hirofumi
2002-04-03 12:21           ` Jos Hulzink
2002-04-03 12:45             ` OGAWA Hirofumi
2002-04-03 12:48             ` David D. Hagood
2002-04-04  0:06               ` Thunder from the hill
2002-03-29 23:11 ` Pavel Machek

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=87663acjs7.fsf@devron.myhome.or.jp \
    --to=hirofumi@mail.parknet.co.jp \
    --cc=helgehaf@aitel.hist.no \
    --cc=linux-kernel@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.