LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@osdl.org>
To: Andries Brouwer <aebr@win.tue.nl>
Cc: linux-kernel@vger.kernel.org
Subject: Re: rfc: test whether a device has a partition table
Date: Wed, 24 Sep 2003 17:18:15 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.44.0309241710380.1688-100000@home.osdl.org> (raw)
In-Reply-To: <20030924235041.GA21416@win.tue.nl>
On Thu, 25 Sep 2003, Andries Brouwer wrote:
>
> Ha, Linus - didn't you know I am always right?
Yeah, sure. But ...
> But being right in theory - like you say, I have repeated these
> things for many years - is not enough to submit a kernel patch.
> The post of today was prompted by a mail about
> certain USB devices:
>
> > On closer examination it seems to be the partition table
> > which is read ok (as one partition) on W2K and XP
> > but Linux (both 2.4 and 2.6) gets really confused and
> > thinks there are 4 malformed partitions.
So? There's a bug, and we'll fix it.
The _worst_ thing that can happen is that you have four extra (totally
bogus) partitions, and you end up using the whole device.
That's my point about partitioning - not that it's necessarily perfect,
but even when it _isn't_ perfect, it's no worse than not partitioning at
all.
I know you don't want the kernel to partition at all. But I don't see your
point.
> > Linux probably needs to handle this situation more
> > gracefully. A local police force bought a bunch of
> > these devices for Linux based forensic work. They
> > are a bit disappointed at the moment.
>
> So, now not only theory but also practice is involved, and
> we must do something.
Why don't they just read the whole device, if that is what they want to
do?
So we have two cases:
a) we have a bug in the partitioning code, and don't parse the partition
table right:
- let's fix the bug
b) people don't want to read the partition info at all, as it's bogus
- use the whole-device node.
In neither case is your "the kernel shouldn't guess" argument the answer,
as far as I can see. And in both cases you _can_ fix it up in user mode if
you know how, so clearly the kernel was no worse off guessing.
Linus
next prev parent reply other threads:[~2003-09-25 0:18 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-24 20:29 Andries.Brouwer
2003-09-24 21:54 ` Linus Torvalds
2003-09-24 23:50 ` Andries Brouwer
2003-09-25 0:05 ` viro
2003-09-25 12:14 ` Andries Brouwer
2003-09-25 0:18 ` Linus Torvalds [this message]
2003-09-25 6:53 ` Xavier Bestel
2003-09-25 10:57 ` Andries Brouwer
2003-09-25 4:47 ` Linus Torvalds
2003-09-25 4:56 ` Linus Torvalds
2003-09-25 11:42 ` Andries Brouwer
2003-10-05 9:00 ` Meelis Roos
2003-09-25 0:42 ` Douglas Gilbert
2003-09-25 1:00 ` viro
2003-09-25 1:27 ` Douglas Gilbert
2004-05-22 11:18 Uwe Bonnes
2004-05-22 12:37 ` John Bradford
2004-05-22 12:56 ` Andries Brouwer
2004-05-22 15:14 ` Uwe Bonnes
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=Pine.LNX.4.44.0309241710380.1688-100000@home.osdl.org \
--to=torvalds@osdl.org \
--cc=aebr@win.tue.nl \
--cc=linux-kernel@vger.kernel.org \
--subject='Re: rfc: test whether a device has a partition table' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).