Linux/Linus/Anton/Alan,
I am still sending out the NTFS repair tools for Linux trashed volumes,
and I've lost count now relative to how many I've sent out, but it's
somewhere in the thousands. Is NTFS write stable enough now in 2.4 to
fix these problems, if so, can we DISABLE by REMOVING write code in the
VFS tables for those versions in other trees we know will trash people's
drives. I am sending out over 100 copies a week now (I could make a
business out of fixing NTFS drives trashed by Linux) and the numbers are
getting higher instead of lower of people asking for these tools, which
woul indicate more people's data is getting trashed.
Do folks not know this NTFS driver will trash hard drives? We need to
alert folks DO NOT USE WRITE NTFS MODE in those versions we know are
busted. I enjoy helping NT customers get their data back and helping
with this problem, but at some point, the NTFS driver either needs to
get sync'd or WRITE disabled. What I'm doing here is like trying to put
a bandaid over the mouth of the amazon river, and as Linux grows and
grows and grows, this problem will just get larger, and to a point where
I don't have the bandwidth to support it properly.
I will keep providing this service, but I am only treating the symptons
of the illness and not curing the patient. Based upon the level of
contamination of TRG with Microsoft IP, I have been advised if I post an
NTFS replacement before the 18 month doctrine of inevitability "window"
is past, Microsoft will most certainly sue us, and win.
I strongly recommend stubbing our the file_write() calls in the NTFS VFS
until this gets fixed, until I can get working NTFS out there, or Anton
can get one out there (which will be another year and a half if it comes
from us based on the agreements we have with Microsoft).
:-)
Jeff
[Jeff Merkey]
> Do folks not know this NTFS driver will trash hard drives? We need
> to alert folks DO NOT USE WRITE NTFS MODE in those versions we know
> are busted.
Here's an idea: let's make r/w support a separate CONFIG option, and
label it "DANGEROUS".
Oh wait, we already do that.
Perhaps we should warn users to back up their NTFS partitions before
trying this option. Put that warning in the help text for
CONFIG_NTFS_RW.
Oh wait, we already do that too.
How stupid does one have to be in order to enable an option labeled
"DANGEROUS" for a non-experimental system?
Peter
Peter Samuelson wrote:
>
> [Jeff Merkey]
> > Do folks not know this NTFS driver will trash hard drives? We need
> > to alert folks DO NOT USE WRITE NTFS MODE in those versions we know
> > are busted.
>
> Here's an idea: let's make r/w support a separate CONFIG option, and
> label it "DANGEROUS".
>
> Oh wait, we already do that.
>
> Perhaps we should warn users to back up their NTFS partitions before
> trying this option. Put that warning in the help text for
> CONFIG_NTFS_RW.
>
> Oh wait, we already do that too.
>
> How stupid does one have to be in order to enable an option labeled
> "DANGEROUS" for a non-experimental system?
Agree. We need to disable it, since folks do not read the docs
(obviously). Of course, we could leave it on, and I could start
charging money for these tools -- there's little doubt it would be a
lucrative business. Perhaps this is what I'll do if the numbers of
copies keeps growing. When it hits > 100 per week, it's taking a lot of
our time to support, so I will have to start charging for it.
Jeff
Jeff
>
> Peter
On Thu, Dec 07, 2000 at 09:43:24PM -0700, Jeff V. Merkey wrote:
> Peter Samuelson wrote:
> >
> > [Jeff Merkey]
> > > Do folks not know this NTFS driver will trash hard drives? We need
> > > to alert folks DO NOT USE WRITE NTFS MODE in those versions we know
> > > are busted.
> > Here's an idea: let's make r/w support a separate CONFIG option, and
> > label it "DANGEROUS".
> > Oh wait, we already do that.
> > Perhaps we should warn users to back up their NTFS partitions before
> > trying this option. Put that warning in the help text for
> > CONFIG_NTFS_RW.
> > Oh wait, we already do that too.
> > How stupid does one have to be in order to enable an option labeled
> > "DANGEROUS" for a non-experimental system?
> Agree. We need to disable it, since folks do not read the docs
> (obviously). Of course, we could leave it on, and I could start
> charging money for these tools -- there's little doubt it would be a
> lucrative business. Perhaps this is what I'll do if the numbers of
> copies keeps growing. When it hits > 100 per week, it's taking a lot of
> our time to support, so I will have to start charging for it.
Huh?
How disabled do you want it. It can't even be enabled unless
you enabled experimental code options. Then, it's disabled by default
and you first have to enable the R/O NTFS. Then you have to explicitly
select the option to enable RW access that is clearly labeled DANGEROUS.
This thing is not armed and dangerous due to an act of ommision. It's
live and active only through three acts of commision.
About the only thing left, short of removing it from the kernel
entirely, is to make the option a hidden control option, like some of the
debugging options, that requires editing a header file or a Makefile to
enable. Is that what you are looking for?
> Jeff
> Jeff
> >
> > Peter
Mike
--
Michael H. Warfield | (770) 985-6132 | [email protected]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
"Michael H. Warfield" wrote:
> > Agree. We need to disable it, since folks do not read the docs
> > (obviously). Of course, we could leave it on, and I could start
> > charging money for these tools -- there's little doubt it would be a
> > lucrative business. Perhaps this is what I'll do if the numbers of
> > copies keeps growing. When it hits > 100 per week, it's taking a lot of
> > our time to support, so I will have to start charging for it.
>
> Huh?
>
> How disabled do you want it. It can't even be enabled unless
> you enabled experimental code options. Then, it's disabled by default
> and you first have to enable the R/O NTFS. Then you have to explicitly
> select the option to enable RW access that is clearly labeled DANGEROUS.
> This thing is not armed and dangerous due to an act of ommision. It's
> live and active only through three acts of commision.
>
> About the only thing left, short of removing it from the kernel
> entirely, is to make the option a hidden control option, like some of the
> debugging options, that requires editing a header file or a Makefile to
> enable. Is that what you are looking for?
>
Linux today monitors this list. Some public education may be the best
route. How do we post a security advisory warning people that will get
posted? I'm sure folks see the DANGEROUS comments, but they don't seem
to stick in their heads. Then they get themselves into trouble, and
fortunately for them, I'm around. I am just concerned about the scope
of the black eye that will just keep getting bigger and bigger for Linux
NTFS.
:-)
Jeff
[Michael Warfield]
> This thing is not armed and dangerous due to an act of ommision.
> It's live and active only through three acts of commision.
We could make it *four* acts of commission. (: (: (:
diff -urk~ fs/Config.in
--- fs/Config.in~ Mon Nov 13 01:43:42 2000
+++ fs/Config.in Thu Dec 7 23:00:34 2000
@@ -37,7 +37,8 @@
tristate 'Minix fs support' CONFIG_MINIX_FS
tristate 'NTFS file system support (read only)' CONFIG_NTFS_FS
-dep_mbool ' NTFS write support (DANGEROUS)' CONFIG_NTFS_RW $CONFIG_NTFS_FS $CONFIG_EXPERIMENTAL
+dep_mbool ' NTFS write support (DANGEROUS)' CONFIG_MORON $CONFIG_NTFS_FS $CONFIG_EXPERIMENTAL
+dep_bool ' Are you sure? I hope you dont care about your NTFS filesystems' CONFIG_NTFS_RW $CONFIG_MORON
tristate 'OS/2 HPFS file system support' CONFIG_HPFS_FS
Linus/Alan,
Please consider the attached patch to make it a little bit harder for
folks to enable NTFS Write Support under Linux until it can get fixed
properly.
Jeff
Peter Samuelson wrote:
>
> [Michael Warfield]
> > This thing is not armed and dangerous due to an act of ommision.
> > It's live and active only through three acts of commision.
>
> We could make it *four* acts of commission. (: (: (:
>
> diff -urk~ fs/Config.in
> --- fs/Config.in~ Mon Nov 13 01:43:42 2000
> +++ fs/Config.in Thu Dec 7 23:00:34 2000
> @@ -37,7 +37,8 @@
> tristate 'Minix fs support' CONFIG_MINIX_FS
>
> tristate 'NTFS file system support (read only)' CONFIG_NTFS_FS
> -dep_mbool ' NTFS write support (DANGEROUS)' CONFIG_NTFS_RW $CONFIG_NTFS_FS $CONFIG_EXPERIMENTAL
> +dep_mbool ' NTFS write support (DANGEROUS)' CONFIG_MORON $CONFIG_NTFS_FS $CONFIG_EXPERIMENTAL
> +dep_bool ' Are you sure? I hope you dont care about your NTFS filesystems' CONFIG_NTFS_RW $CONFIG_MORON
>
> tristate 'OS/2 HPFS file system support' CONFIG_HPFS_FS
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
[Jeff Merkey]
> Please consider the attached patch to make it a little bit harder for
> folks to enable NTFS Write Support under Linux until it can get fixed
> properly.
Hey! It was a joke! A better way would be just to comment out the
CONFIG_NTFS_RW line entirely. Actually, I think that *would* be a good
idea. Anyone who has any business messing with NTFS_RW is more than
capable of editing Config.in.
Peter
On Fri, Dec 08, 2000 at 12:06:23AM -0600, Peter Samuelson wrote:
>
> [Jeff Merkey]
> > Please consider the attached patch to make it a little bit harder for
> > folks to enable NTFS Write Support under Linux until it can get fixed
> > properly.
>
> Hey! It was a joke! A better way would be just to comment out the
> CONFIG_NTFS_RW line entirely. Actually, I think that *would* be a good
> idea. Anyone who has any business messing with NTFS_RW is more than
> capable of editing Config.in
Even better, this will disable it. For now, it's probably for the
best. Microsoft has been extremely tolerant in allowing me to help
these customers, but if it turns into a wide-scale software distribution
business, I can see them sending lawyers my way. If I personally touch
the NTFS driver in Linux before some reasonable legal limit expires,
they could do some very unpleasant things.
:-)
Jeff
>
> Peter
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
Hearing how many people trash their partition I would agree to comment out
the NTFS write option altogether. I will make a patch for both 2.4.0-testX
and 2.2.18latest and send them off to Linus/Alan over the weekend if no one
beats me to it.
Considering that people are blatantly ignoring all our warnings this might
be the Right Thing(TM) as it is easy enough to activate the option if
someone really wants/needs to use it. That should hopefully lower the
amount of incidents with people trashing their partitions[1][2].
Anton
[1] On the other hand it might not help much as people might just uncomment
it and go ahead using it, but there is a limit to how far we can go without
taking out the write part of the driver altogether! Which might actually
not be a Bad Thing(TM) were it not for the fact that having the write
support can actually help in fixing a trashed partition when people know
what they are doing...i.e. when they know what they can do safely and what
not. - It's saved me from loosing 10Gb+ of non-backed up data in the past!
[2] My NTFS repair utility is under development albeit very slowly which
should help a little bit once I have a stable release. - Initial release is
yet TBA as there are some very strange bugs in it at the moment, which
might actually turn out to be bugs in the compiler/libc/kernel as the
program runs fine sometimes and sometimes corrupts the partitions slightly,
operating on the _exact_ same partition with the _exact_ same data on it! -
Anyway, I am not releasing this to the public before I have figured out WTH
is going on...
At 06:06 08/12/2000, Peter Samuelson wrote:
>[Jeff Merkey]
> > Please consider the attached patch to make it a little bit harder for
> > folks to enable NTFS Write Support under Linux until it can get fixed
> > properly.
>
>Hey! It was a joke! A better way would be just to comment out the
>CONFIG_NTFS_RW line entirely. Actually, I think that *would* be a good
>idea. Anyone who has any business messing with NTFS_RW is more than
>capable of editing Config.in.
>
>Peter
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>Please read the FAQ at http://www.tux.org/lkml/
--
"Education is what remains after one has forgotten everything he
learned in school." - Albert Einstein
--
Anton Altaparmakov Voice: +44-(0)1223-333541(lab) / +44-(0)7712-632205(mobile)
Christ's College eMail: [email protected] / [email protected]
Cambridge CB2 3BU ICQ: 8561279
United Kingdom WWW: http://www-stu.christs.cam.ac.uk/~aia21/
"Peter Samuelson wrote:"
> [Michael Warfield]
> > This thing is not armed and dangerous due to an act of ommision.
> > It's live and active only through three acts of commision.
>
> We could make it *four* acts of commission. (: (: (:
>
> diff -urk~ fs/Config.in
> --- fs/Config.in~ Mon Nov 13 01:43:42 2000
> +++ fs/Config.in Thu Dec 7 23:00:34 2000
> @@ -37,7 +37,8 @@
> tristate 'Minix fs support' CONFIG_MINIX_FS
>
> tristate 'NTFS file system support (read only)' CONFIG_NTFS_FS
> -dep_mbool ' NTFS write support (DANGEROUS)' CONFIG_NTFS_RW $CONFIG_NTFS_FS $CONFIG_EXPERIMENTAL
> +dep_mbool ' NTFS write support (DANGEROUS)' CONFIG_MORON $CONFIG_NTFS_FS $CONFIG_EXPERIMENTAL
> +dep_bool ' Are you sure? I hope you dont care about your NTFS filesystems' CONFIG_NTFS_RW $CONFIG_MORON
>
> tristate 'OS/2 HPFS file system support' CONFIG_HPFS_FS
Of course, you know that it *WILL NOT* work as CONFIG_MORON is nowhere
defined ... ?
Andrzej
--
=======================================================================
Andrzej M. Krzysztofowicz [email protected]
phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math., Technical University of Gdansk
At 11:54 PM 12/7/00, Jeff V. Merkey wrote:
>Linux today monitors this list. Some public education may be the best
>route. How do we post a security advisory warning people that will get
>posted? I'm sure folks see the DANGEROUS comments, but they don't seem
>to stick in their heads. Then they get themselves into trouble, and
>fortunately for them, I'm around. I am just concerned about the scope
>of the black eye that will just keep getting bigger and bigger for Linux
>NTFS.
FWIW, Mandrake Linux includes a tool MandrakeUpdate which allows
downloading of "Normal Updates" or "Development Updates". If you chose
Devel Upd, you get the following warning:
Caution ! These packages are NOT well tested.
You really can screw up your system
by installing them.
Perhaps the configure tools could recognize a DANGEROUS status (or keyword
or ???) and would display such a message ...
David
On Fri, Dec 08, 2000 at 08:19:46AM -0500, David Relson wrote:
> At 11:54 PM 12/7/00, Jeff V. Merkey wrote:
>
>
> >Linux today monitors this list. Some public education may be the best
> >route. How do we post a security advisory warning people that will get
> >posted? I'm sure folks see the DANGEROUS comments, but they don't seem
> >to stick in their heads. Then they get themselves into trouble, and
> >fortunately for them, I'm around. I am just concerned about the scope
> >of the black eye that will just keep getting bigger and bigger for Linux
> >NTFS.
>
>
> FWIW, Mandrake Linux includes a tool MandrakeUpdate which allows
> downloading of "Normal Updates" or "Development Updates". If you chose
> Devel Upd, you get the following warning:
>
> Caution ! These packages are NOT well tested.
> You really can screw up your system
> by installing them.
>
> Perhaps the configure tools could recognize a DANGEROUS status (or keyword
> or ???) and would display such a message ...
No amount of warnings can prevent morons from f**king up. Unix gives
you enough rope et al. I'm not arguing for removal of any warning, but
seriously, if we have a loud (DANGEROUS) warning in the config-system
aaaaaand a warning in the help-text that the write-support probably will
mess up your fs, how much more can you do? I bet that if we remove the
config-option, people will still enable it manually, then go "Waaaaa,
your stupid kernel messed up my filesystem, Linux sucks!"
But I kind of liked the
Enable write support (DANGEROUS)
Really enable write support (DANGEROUS)
Are you f**king nuts?!
approach anyway. A strong candidate for Rik van Riel's patch-of-the-month
homepage.
/David
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
> somewhere in the thousands. Is NTFS write stable enough now in 2.4 to
> fix these problems, if so, can we DISABLE by REMOVING write code in the
It says DANGEROUS in big letters on the configuration option. We are now
down to the level of people who don't understand 'smoking kills you' in big
letters on packaging, and people using very old trees that merely warned you
that it was a very bad idea
Alan
> Agree. We need to disable it, since folks do not read the docs
> (obviously). Of course, we could leave it on, and I could start
> charging money for these tools -- there's little doubt it would be a
> lucrative business. Perhaps this is what I'll do if the numbers of
> copies keeps growing. When it hits > 100 per week, it's taking a lot of
> our time to support, so I will have to start charging for it.
I am very firmly against removing something because people do not read manuals,
what is next fdisk , mkfs ?.
On Fri, 8 Dec 2000, Alan Cox wrote:
> I am very firmly against removing something because people do
> not read manuals, what is next fdisk , mkfs ?.
I must say I like the CONFIG_MORON though. By setting that the
(l)user exposes his true identity and leaves little for us to
doubt ;)
Added to the Patch of the Month page as suggested by David
Weinehall:
http://www.surriel.com/potm/
regards,
Rik
--
Hollywood goes for world dumbination,
Trailer at 11.
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
On Fri, Dec 08, 2000 at 02:43:42PM +0100, David Weinehall wrote:
> On Fri, Dec 08, 2000 at 08:19:46AM -0500, David Relson wrote:
> > At 11:54 PM 12/7/00, Jeff V. Merkey wrote:
> No amount of warnings can prevent morons from f**king up. Unix gives
> you enough rope et al. I'm not arguing for removal of any warning, but
> seriously, if we have a loud (DANGEROUS) warning in the config-system
> aaaaaand a warning in the help-text that the write-support probably will
> mess up your fs, how much more can you do? I bet that if we remove the
Well, simply insert sth. like this into ./fs/ntfs/fs.c:parse_options()
printk(KERN_EMERG "You're likely to crash your NTFS if you do any "
"write attempts to it. NTFS write support is broken and for "
"developers *only*. Do only use this if you're debugging it, "
"never ever use this on data you'd like to see tomorrow "
"again!!! Please remount in read-only mode *now* or don't "
"complain afterwards!");
Maybe that can prevent pupils^H^H^H^H^Heople from shooting their
foots...
MfG, JBG
--
Fehler eingestehen, Gr??e zeigen: Nehmt die Rechtschreibreform zur?ck!!!
/* Jan-Benedict Glaw <[email protected]> -- +49-177-5601720 */
keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB
"insmod vi.o and there we go..." (Alexander Viro on linux-kernel)
You know, couldn't we do something like prompting the (l)user with an
disclaimer/agreement or something when selecting the option or maybe
even when doing a make dep?
They'd prolly blast through it without reading (You don't think they
read teh MS agreement when istalling windows do you?) but I bet we could
argue that they accepted the agreement to protect us.
Rik:
I got a little diff happy ;-P
--- index.html.old Fri Dec 8 09:35:58 2000
+++ index.html Fri Dec 8 09:38:03 2000
@@ -21,7 +21,7 @@
<p>If you spot a gem that's suitable for placement on this
page, please <a href="mailto:[email protected]">mail me</a>.
-<p><address>Rik van Riel, feb 11 2000</address>
+<p><address>Rik van Riel, dec 08 2000</address>
<table width=100%><tr>
<td><a href="/">Back to surriel.com</a>
@@ -31,14 +31,14 @@
<hr>
<ul>
-<li>April 2000: <a href="dec2000.shtml">fs/Config.in</a> by
+<li>December 2000: <a href="dec2000.shtml">fs/Config.in</a> by
Peter Samuelson.
+<li>June 2000: <a href="jun2000.shtml">kernel/sys.c patch</a> by
+ Dominik Rothert.
<li>April 2000: <a href="apr2000.shtml">drivers/block/floppy.c</a> by
Tim Waugh.
<li>February 2000: <a href="feb2000.shtml">mm/swapfile.c patch</a> by
Aaron Botsis.
-<li>June 2000: <a href="jun2000.shtml">kernel/sys.c patch</a> by
- Dominik Rothert.
</ul>
</body>
On Fri, 8 Dec 2000, Rik van Riel wrote:
> I must say I like the CONFIG_MORON though. By setting that the
> (l)user exposes his true identity and leaves little for us to
> doubt ;)
>
> Added to the Patch of the Month page as suggested by David
> Weinehall:
>
> http://www.surriel.com/potm/
>
--
=====================================================================
Mohammad A. Haque http://www.haque.net/
[email protected]
"Alcohol and calculus don't mix. Project Lead
Don't drink and derive." --Unknown http://wm.themes.org/
[email protected]
=====================================================================
Peter Samuelson wrote:
>
> [Jeff Merkey]
> > Please consider the attached patch to make it a little bit harder for
> > folks to enable NTFS Write Support under Linux until it can get fixed
> > properly.
>
> Hey! It was a joke! A better way would be just to comment out the
> CONFIG_NTFS_RW line entirely. Actually, I think that *would* be a good
> idea. Anyone who has any business messing with NTFS_RW is more than
> capable of editing Config.in.
Agreed. I would prefer that filesystems with known broken write support
depend on CONFIG_BROKEN (which would be always defined to 'n')
Jeff
--
Jeff Garzik |
Building 1024 | These are not the J's you're lookin' for.
MandrakeSoft | It's an old Jedi mind trick.
On Fri, 8 Dec 2000, Rik van Riel wrote:
> On Fri, 8 Dec 2000, Alan Cox wrote:
>
> > I am very firmly against removing something because people do
> > not read manuals, what is next fdisk , mkfs ?.
>
> I must say I like the CONFIG_MORON though. By setting that the
> (l)user exposes his true identity and leaves little for us to
> doubt ;)
>
> Added to the Patch of the Month page as suggested by David
> Weinehall:
>
> http://www.surriel.com/potm/
>
> regards,
>
Question. Which of the following files will first be executed if
found in a distribution?
Script started on Fri Dec 8 09:34:17 2000
# pwd
/DANGER/DANGER/DANGER
# ls -la
total 3128
drwxr-xr-x 2 root root 4096 Dec 8 09:34 .
drwxrwxrwx 3 root root 4096 Dec 8 09:32 ..
-rwxr-xr-x 1 root root 634503 Dec 8 09:33 corruption
-rwxr-xr-x 1 root root 634503 Dec 8 09:33 death
-rwxr-xr-x 1 root root 634503 Dec 8 09:32 do_not_execute
-rwxr-xr-x 1 root root 634503 Dec 8 09:33 this_can_break_your_machine
-rwxr-xr-x 1 root root 634503 Dec 8 09:33 this_is_harmful
# exit
exit
Script done on Fri Dec 8 09:34:39 2000
Answer; Anything that looks exciting. I'd go for death, but the less bold
might try corruption first. Things that are only harmful get no attention
at all.
In the 'olden' days, stuff in /sbin was considered off-limits without
the explicit written documentation at hand (Try to partition a hard-
disk under Ultrix). When asked; "Do you want to write (Y/N)?", the
answers were not Y/N! You had to look in the documentation and
find that the only way to commit the write was by typing
"Yes, absolutely, positively!"
This helped keep the learners from destroying their systems.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
[email protected] said:
> They'd prolly blast through it without reading (You don't think they
> read teh MS agreement when istalling windows do you?) but I bet we
> could argue that they accepted the agreement to protect us.
tristate 'NTFS file system support (read only)' CONFIG_NTFS_FS
dep_mbool ' NTFS write support (DANGEROUS)' CONFIG_NTFS_RW $CONFIG_NTFS_FS $CONFIG_EXPERIMENTAL
if [ "$CONFIG_NTFS_RW" = "y" ] ; then
string ' Enter the magic text to really enable NTFS write' CONFIG_NTFS_MAGICTEXT
fi
#ifdef CONFIG_NTFS_RW
#if CONFIG_NTFS_MAGICTEXT != "I know it will eat my filesystem"
#error you got the magic text wrong
#endif
#endif
--
dwmw2
On Fri, Dec 08, 2000 at 03:34:09PM +0100, Jan-Benedict Glaw wrote:
[...]
> Maybe that can prevent pupils^H^H^H^H^Heople from shooting their
> foots...
Nothing can "prevent" them from shooting themselves in the foot,
even taking away their guns and ammunition (removing it from the kernel)
is rarely sufficient for the really skillfull and determined foot
shooters (they want it, they'll patch it back in and complain about the
inconvenience).
We can make it more difficult and make sure they understand that
it's a self inflicted injury when it happens to them, but we can not
prevent it.
Application Programmers Saying: "Software development is a race
between software engineers who are attempting to create fool proof programs
and the Universe which is attempting to create bigger and better fools."
Software Engineers Saying: "So far, the Universe is winning."
> MfG, JBG
>
> --
> Fehler eingestehen, Gr??e zeigen: Nehmt die Rechtschreibreform zur?ck!!!
> /* Jan-Benedict Glaw <[email protected]> -- +49-177-5601720 */
> keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB
> "insmod vi.o and there we go..." (Alexander Viro on linux-kernel)
Mike
--
Michael H. Warfield | (770) 985-6132 | [email protected]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
On Fri, Dec 08, 2000 at 01:55:43PM +0000, Alan Cox wrote:
> > somewhere in the thousands. Is NTFS write stable enough now in 2.4 to
> > fix these problems, if so, can we DISABLE by REMOVING write code in the
>
> It says DANGEROUS in big letters on the configuration option. We are now
> down to the level of people who don't understand 'smoking kills you' in big
> letters on packaging, and people using very old trees that merely warned you
> that it was a very bad idea
I agree that if you give a mentally unbalanced person a firearm, they might
shoot themselves with it. I am suggesting we take away their firearm. Write
support for NTFS is useful for migrating from Linux to NT, R/O support is
useful for migrating NT to Linux. We won't be giving anything up. I think
just putting in a nastier warning message would suffice.
Jeff
>
> Alan
On Fri, Dec 08, 2000 at 02:00:29PM +0000, Alan Cox wrote:
> > Agree. We need to disable it, since folks do not read the docs
> > (obviously). Of course, we could leave it on, and I could start
> > charging money for these tools -- there's little doubt it would be a
> > lucrative business. Perhaps this is what I'll do if the numbers of
> > copies keeps growing. When it hits > 100 per week, it's taking a lot of
> > our time to support, so I will have to start charging for it.
>
> I am very firmly against removing something because people do not read manuals,
> what is next fdisk , mkfs ?.
We should put in a nastier message then. It WILL DESTROY DATA IRREPARABLY
and I've got even more bad news -- because it's in Linux, Microsoft is already
altering the on-disk structures again, so it's about to be broken in R/O
mode as well when Whistler comes out.
:-)
Jeff
On Fri, Dec 08, 2000 at 03:34:09PM +0100, Jan-Benedict Glaw wrote:
> On Fri, Dec 08, 2000 at 02:43:42PM +0100, David Weinehall wrote:
> > On Fri, Dec 08, 2000 at 08:19:46AM -0500, David Relson wrote:
> > > At 11:54 PM 12/7/00, Jeff V. Merkey wrote:
>
> > No amount of warnings can prevent morons from f**king up. Unix gives
> > you enough rope et al. I'm not arguing for removal of any warning, but
> > seriously, if we have a loud (DANGEROUS) warning in the config-system
> > aaaaaand a warning in the help-text that the write-support probably will
> > mess up your fs, how much more can you do? I bet that if we remove the
>
> Well, simply insert sth. like this into ./fs/ntfs/fs.c:parse_options()
>
> printk(KERN_EMERG "You're likely to crash your NTFS if you do any "
> "write attempts to it. NTFS write support is broken and for "
> "developers *only*. Do only use this if you're debugging it, "
> "never ever use this on data you'd like to see tomorrow "
> "again!!! Please remount in read-only mode *now* or don't "
> "complain afterwards!
And add:
If you persist in using this, http://www.timpanogas.org will provide
tools to help you recover your data.);
Jeff
");
>
> Maybe that can prevent pupils^H^H^H^H^Heople from shooting their
> foots...
>
> MfG, JBG
>
> --
> Fehler eingestehen, Gr??e zeigen: Nehmt die Rechtschreibreform zur?ck!!!
> /* Jan-Benedict Glaw <[email protected]> -- +49-177-5601720 */
> keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB
> "insmod vi.o and there we go..." (Alexander Viro on linux-kernel)
"Jeff V. Merkey" wrote:
>
> On Fri, Dec 08, 2000 at 02:00:29PM +0000, Alan Cox wrote:
> > > Agree. We need to disable it, since folks do not read the docs
> > > (obviously). Of course, we could leave it on, and I could start
> > > charging money for these tools -- there's little doubt it would be a
> > > lucrative business. Perhaps this is what I'll do if the numbers of
> > > copies keeps growing. When it hits > 100 per week, it's taking a lot of
> > > our time to support, so I will have to start charging for it.
> >
> > I am very firmly against removing something because people do not read manuals,
> > what is next fdisk , mkfs ?.
>
> We should put in a nastier message then. It WILL DESTROY DATA IRREPARABLY
> and I've got even more bad news -- because it's in Linux, Microsoft is already
> altering the on-disk structures again, so it's about to be broken in R/O
> mode as well when Whistler comes out.
We don't need any messages. If (DANGEROUS) is not sufficient, then
disable the feature unconditionally. Someone hacking on the code will
be smart enough to enable the stuff while they are debugging.
Jeff
--
Jeff Garzik |
Building 1024 | These are not the J's you're lookin' for.
MandrakeSoft | It's an old Jedi mind trick.
On Fri, Dec 08, 2000 at 12:42:45PM -0500, Jeff Garzik wrote:
> "Jeff V. Merkey" wrote:
>
> We don't need any messages. If (DANGEROUS) is not sufficient, then
> disable the feature unconditionally. Someone hacking on the code will
> be smart enough to enable the stuff while they are debugging.
>
> Jeff
>
You guys make the call. I will be here to catch the 100+ messages that would
normally be posting to the kernel list with "Linux destroyed my data", and
I have been handling them. I am just alerting you guys that the numbers
of people needing this are increasing, which is an indication more and more
people are using Linux to migrate NT to Linux, and vice-versa, and getting
themselves into trouble. We need to brainstorm a more long term solution
for this problem. I suspect if I post these tools on our FTP server
for free download, MS will promptly show up with attorneys. Normally, this
is what I would do, but these tools were developed via access to MS IP,
and so long as I am helping MS customers recover data in a "consulting"
capacity, I do not believe they will interfere, particularly since
everytime this happens, Linux gets a great big black eye with the
affected customer. But very soon (like after 2.4 ships) the numbers
of folks needing this may increase to a capacity I cannot support
properly without dumping these tools into general distribution -- then
the shit will hit the fan with MS if I do this.
:-)
Jeff
> --
> Jeff Garzik |
> Building 1024 | These are not the J's you're lookin' for.
> MandrakeSoft | It's an old Jedi mind trick.
On Fri, Dec 08, 2000 at 07:37:55AM +0000, Anton Altaparmakov wrote:
> Hearing how many people trash their partition I would agree to comment out
> the NTFS write option altogether. I will make a patch for both 2.4.0-testX
> and 2.2.18latest and send them off to Linus/Alan over the weekend if no one
> beats me to it.
>
> Considering that people are blatantly ignoring all our warnings this might
> be the Right Thing(TM) as it is easy enough to activate the option if
> someone really wants/needs to use it. That should hopefully lower the
> amount of incidents with people trashing their partitions[1][2].
>
> Anton
>
> [1] On the other hand it might not help much as people might just uncomment
> it and go ahead using it, but there is a limit to how far we can go without
> taking out the write part of the driver altogether! Which might actually
> not be a Bad Thing(TM) were it not for the fact that having the write
> support can actually help in fixing a trashed partition when people know
> what they are doing...i.e. when they know what they can do safely and what
> not. - It's saved me from loosing 10Gb+ of non-backed up data in the past!
>
> [2] My NTFS repair utility is under development albeit very slowly which
> should help a little bit once I have a stable release. - Initial release is
> yet TBA as there are some very strange bugs in it at the moment, which
> might actually turn out to be bugs in the compiler/libc/kernel as the
> program runs fine sometimes and sometimes corrupts the partitions slightly,
> operating on the _exact_ same partition with the _exact_ same data on it! -
> Anyway, I am not releasing this to the public before I have figured out WTH
> is going on...
Anton,
I will be able to help "officially" in another 14 months, when the
inevitability window is closed. Unfortunately, by then, MS will
have altered the on-disk structures again, makeing the job even harder.
You and Alan should Brainstorm a solution. Removing write support or
putting in a disclaimer would suffice. It's your call, BTW along
with Alan.
:-)
Jeff
>
>I agree that if you give a mentally unbalanced person a firearm, they might
>shoot themselves with it. I am suggesting we take away their firearm. Write
>support for NTFS is useful for migrating from Linux to NT, R/O support is
>useful for migrating NT to Linux. We won't be giving anything up. I think
>just putting in a nastier warning message would suffice.
>
>Jeff
You could just tell people the truth. Something far worse that DANGEROUS.
Like:
CRIPPLED BY LEGAL DURESS
Or as I come to understand:
The processes that would normally have fixed this driver by now
are broken by the vigorous defense of Microsoft's IP.
It will trash your disk! maybe not right now ..
I couldn't understand why I hadn't seen any real movement on this driver.
Now it makes sense. Perhaps others might enjoy this understanding.
Mark
One problem with warnings at compile time is that in many cases, administrators
use kernels provided by friends or collegues that "know linux better than them".
If an admin uses a kernel in which write support has been activated to mount
an NTFS file system without providing any option, he will get it mount R/W
without any warning, then may destroy it at the first mistake or so.
perhaps we should add an option such as "force" to mount an NTFS r/w, and as
suggested by JBG, print a KERN_EMERG message when attempting to mount it r/w
without the "force" option.
we could also add a static counter which will make the first r/w mount always
fail, to ensure people will read the message, and which would prevent people
from mounting r/w from fstab.
just my $0.02.
BTW, I like the message about microsoft preventing from fixing the driver ;-)
Cheers,
Willy
On Sat, Dec 09, 2000 at 05:49:00PM +0100, Willy Tarreau wrote:
> One problem with warnings at compile time is that in many cases, administrators
> use kernels provided by friends or collegues that "know linux better than them".
> If an admin uses a kernel in which write support has been activated to mount
> an NTFS file system without providing any option, he will get it mount R/W
> without any warning, then may destroy it at the first mistake or so.
>
> perhaps we should add an option such as "force" to mount an NTFS r/w, and as
> suggested by JBG, print a KERN_EMERG message when attempting to mount it r/w
> without the "force" option.
>
> we could also add a static counter which will make the first r/w mount always
> fail, to ensure people will read the message, and which would prevent people
> from mounting r/w from fstab.
>
> just my $0.02.
>
> BTW, I like the message about microsoft preventing from fixing the driver ;-)
:-) I can fix it in 14 months.
Jeff
>
> Cheers,
> Willy
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
On Sat, Dec 09, 2000 at 05:49:00PM +0100, Willy Tarreau wrote:
Alan has spoken. If DANGEROUS doesn't get their attention, what
will?
Jeff
> One problem with warnings at compile time is that in many cases, administrators
> use kernels provided by friends or collegues that "know linux better than them".
> If an admin uses a kernel in which write support has been activated to mount
> an NTFS file system without providing any option, he will get it mount R/W
> without any warning, then may destroy it at the first mistake or so.
>
> perhaps we should add an option such as "force" to mount an NTFS r/w, and as
> suggested by JBG, print a KERN_EMERG message when attempting to mount it r/w
> without the "force" option.
>
> we could also add a static counter which will make the first r/w mount always
> fail, to ensure people will read the message, and which would prevent people
> from mounting r/w from fstab.
>
> just my $0.02.
>
> BTW, I like the message about microsoft preventing from fixing the driver ;-)
>
> Cheers,
> Willy
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
"Jeff V. Merkey" <[email protected]> writes:
> On Fri, Dec 08, 2000 at 02:00:29PM +0000, Alan Cox wrote:
> > > Agree. We need to disable it, since folks do not read the docs
> > > (obviously). Of course, we could leave it on, and I could start
> > > charging money for these tools -- there's little doubt it would be a
> > > lucrative business. Perhaps this is what I'll do if the numbers of
> > > copies keeps growing. When it hits > 100 per week, it's taking a lot of
> > > our time to support, so I will have to start charging for it.
> >
> > I am very firmly against removing something because people do not read
> manuals,
>
> > what is next fdisk , mkfs ?.
>
> We should put in a nastier message then. It WILL DESTROY DATA IRREPARABLY
> and I've got even more bad news -- because it's in Linux, Microsoft is already
> altering the on-disk structures again, so it's about to be broken in R/O
> mode as well when Whistler comes out.
Hmm. If this is the case then shouldn't someone point this out. To the
antitrust lawyers. You present this as a clear case of deliberately
preventing interoperability between NT and linux.
The generous side of me suggests that they might be trying to fix some
mistakes, or enhance things. Linux isn't standing still on the fs
format issue either.
Eric
On Sat, Dec 09, 2000 at 03:03:22PM -0700, Eric W. Biederman wrote:
> "Jeff V. Merkey" <[email protected]> writes:
> Hmm. If this is the case then shouldn't someone point this out. To the
> antitrust lawyers. You present this as a clear case of deliberately
> preventing interoperability between NT and linux.
>
> The generous side of me suggests that they might be trying to fix some
> mistakes, or enhance things. Linux isn't standing still on the fs
> format issue either.
>
> Eric
I think the anitrust issues are moot -- they have had their way already
with Microsoft. They've been left beaten and crippled in the eyes of
the general public. Large Customers seem to not be swallowing .NET.
Their behavior is inconsistent with the Trial Judge's ruling. Technically,
by pursuing .NET, they are not observing the spirit of the ruling. If
you get a ruling put on you by a court, you are supposed to observe what
it says and correct your behavior, even if the execution order was stayed
by the court pending appeal. The Judge did not set aside the ruling --
it's still there.
Because of this, any investment in Microsoft strategies by large enterprise
customers are an unknown until the appeals court makes a determination.
Microsoft is also setting itself up for a contempt order by doing this.
The trial court told them to stay out of the internet business with their
operating systems business unit. Their compliance has been illusionary
with the court's ruling, and unless the appeals court vacates the ruling,
they could be in big trouble.
If I were the DOJ, I would already be putting together an OFC for
filing with the trial court. They are also doing the worst possible
thing you can do while a case is on appeal, which is to ignore the
trial court's rulings, and resorting to character assisination of
the trial judge.
Jeff
> Alan has spoken. If DANGEROUS doesn't get their
> attention, what will?
Jeff, I know that, but I was speaking about people who
use these features while they don't know they're
dangerous just because someone else has compiled the
kernel for them. There are people who claim to know
linux better than anyone and consider they are better
than anyone at making kernels or distros. these people
are dangerous for people who trust them blindly. In
this case, a warning at mount time may save ignorant
victims.
Perhaps we should more generally display a line at
boot
telling if there were EXPERIMENTAL or DANGEROUS code
compiled in the kernel.
I myself have built kernels with NTFS R/W enabled a
long time ago to try to recover a crashed NT (bad
dll).
as a chance, I've never gave those kernels to anyone,
but it may have been possible that I accidentely reuse
the boot disk for something else ...
Willy
___________________________________________________________
Do You Yahoo!? -- Pour dialoguer en direct avec vos amis,
Yahoo! Messenger : http://fr.messenger.yahoo.com
On Sun, Dec 10, 2000 at 02:38:03AM +0100, willy tarreau wrote:
>
> Perhaps we should more generally display a line at
> boot
> telling if there were EXPERIMENTAL or DANGEROUS code
> compiled in the kernel.
>
Good idea.
Jeff
I think part of the problem is that there are other things labeled
DANGEROUS that actually do work fairly reliably (offhand, I'm thinking
off the IDE config stuff..). Perhaps it needs to explicitely say
'This is broken and is gauranteed to destroy your data. Do not use it'
The 'DANGEROUS' label seems to suggest that it -may- destroy data, which
leads to the 'it won't happen to me' mentality.
Just my thoughts,
Rene
On Dec 08, Alan Cox wrote:
> > Agree. We need to disable it, since folks do not read the docs
> > (obviously). Of course, we could leave it on, and I could start
> > charging money for these tools -- there's little doubt it would be a
> > lucrative business. Perhaps this is what I'll do if the numbers of
> > copies keeps growing. When it hits > 100 per week, it's taking a lot of
> > our time to support, so I will have to start charging for it.
>
> I am very firmly against removing something because people do not read manuals,
> what is next fdisk , mkfs ?.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
At 08:12 PM 12/9/2000 -0600, Rene wrote:
>I think part of the problem is that there are other things labeled
>DANGEROUS that actually do work fairly reliably (offhand, I'm thinking
>off the IDE config stuff..). Perhaps it needs to explicitely say
>'This is broken and is gauranteed to destroy your data. Do not use it'
>
>The 'DANGEROUS' label seems to suggest that it -may- destroy data, which
>leads to the 'it won't happen to me' mentality.
For what it's worth, I absolutely agree with this. I have the same
impression when I just see the word "dangerous".
--
This message has been brought to you by the letter alpha and the number pi.
Open Source: Think locally; act globally.
David Feuer
[email protected]
On Sat, Dec 09, 2000 at 09:34:59PM -0500, David Feuer wrote:
> At 08:12 PM 12/9/2000 -0600, Rene wrote:
> >I think part of the problem is that there are other things labeled
> >DANGEROUS that actually do work fairly reliably (offhand, I'm thinking
> >off the IDE config stuff..). Perhaps it needs to explicitely say
> >'This is broken and is gauranteed to destroy your data. Do not use it'
> >
> >The 'DANGEROUS' label seems to suggest that it -may- destroy data, which
> >leads to the 'it won't happen to me' mentality.
>
> For what it's worth, I absolutely agree with this. I have the same
> impression when I just see the word "dangerous".
Why not call a spade a spade and label it BROKEN. I do think that's
stronger than DANGEROUS.
- |Daryll
On Sat, 09 Dec 2000 21:34:59 -0500, David Feuer
<[email protected]> wrote:
>At 08:12 PM 12/9/2000 -0600, Rene wrote:
>>I think part of the problem is that there are other things labeled
>>DANGEROUS that actually do work fairly reliably (offhand, I'm thinking
>>off the IDE config stuff..). Perhaps it needs to explicitely say
>>'This is broken and is gauranteed to destroy your data. Do not use it'
>>
>>The 'DANGEROUS' label seems to suggest that it -may- destroy data, which
>>leads to the 'it won't happen to me' mentality.
>
>For what it's worth, I absolutely agree with this. I have the same
>impression when I just see the word "dangerous".
If this was a business, and we were knowingly distributing software
that was known to be dangerous, we would probably be risking legal
action.
Why are we distributing such severely broken software? Heck, we seem
reluctant to include reiserfs, a pretty high quality, supported file
system. And we continue to distribute this !@#$%... There must be some
strange agenda going on to limit the use of Linux.
john alvord
On Sat, 9 Dec 2000, Ren Haddock wrote:
> I think part of the problem is that there are other things labeled
> DANGEROUS that actually do work fairly reliably (offhand, I'm thinking
> off the IDE config stuff..). Perhaps it needs to explicitely say
> 'This is broken and is gauranteed to destroy your data. Do not use it'
DANGEROUS == GO_FOR_IT_DUMB_ARSE_SCREW_YOURSELF_WILDLY
This is the intent, when I put and started the DANGEROUS settings.
Because the volitale nature of extreme alpha code in the beginning.
However as time passed, people did not think it had meaning, but that is
what it orginally was defined by me.
This is UNIX, and to quote one of HPA's signatures,
"unix gives you enough rope to hang yourself"
My personal favorite:
You are going to shoot yourself in the head, aim carefully!
How well you aim determines if you get a second chance!
Cheers,
Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development
PS: for the pc language crowd, note that I use "arse"!!!
[email protected] (John Alvord) said:
[...]
> If this was a business, and we were knowingly distributing software
> that was known to be dangerous, we would probably be risking legal
> action.
Debatable. It is marked EXPERIMENTAL and DANGEROUS, and not enabled by
default.
> Why are we distributing such severely broken software? Heck, we seem
> reluctant to include reiserfs, a pretty high quality, supported file
> system. And we continue to distribute this !@#$%... There must be some
> strange agenda going on to limit the use of Linux.
It is just that NTFS has been in the kernel for ages, and rotted. Nobody
has taken the time to remove it (would be a lot less than what has been
wasted up to now discussing the matter here...).
--
Horst von Brand [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
> You could just tell people the truth. Something far worse that DANGEROUS.
> Like:
>
> CRIPPLED BY LEGAL DURESS
>
> Or as I come to understand:
>
> The processes that would normally have fixed this driver by now
> are broken by the vigorous defense of Microsoft's IP.
> It will trash your disk! maybe not right now ..
>
> I couldn't understand why I hadn't seen any real movement on this driver.
> Now it makes sense. Perhaps others might enjoy this understanding.
This one is a must !!
Let's put it in the kernel conf.
Xav
>>>>> "Daryll" == Daryll Strauss <[email protected]> writes:
Daryll> On Sat, Dec 09, 2000 at 09:34:59PM -0500, David Feuer wrote:
>> For what it's worth, I absolutely agree with this. I have the same
>> impression when I just see the word "dangerous".
Daryll> Why not call a spade a spade and label it BROKEN. I do think
Daryll> that's stronger than DANGEROUS.
I doubt it will make any difference whatever we write. I have seen
several times how users enable every single option because 'they don't
want to miss out on anything'. It's at the order of someone with a
Macintosh enabling something labelled "Atari internal serial port
support" (theoretical example, no offense).
Jes
> Daryll> On Sat, Dec 09, 2000 at 09:34:59PM -0500, David Feuer wrote:
> >> For what it's worth, I absolutely agree with this. I have the same
> >> impression when I just see the word "dangerous".
>
> Daryll> Why not call a spade a spade and label it BROKEN. I do think
> Daryll> that's stronger than DANGEROUS.
>
> I doubt it will make any difference whatever we write. I have seen
> several times how users enable every single option because 'they don't
> want to miss out on anything'. It's at the order of someone with a
> Macintosh enabling something labelled "Atari internal serial port
> support" (theoretical example, no offense).
How about reversed?
The option comes enabled by default, but the coding is change to fit this
below:
<M> NTFS support
[*] disable ntfs write support
But after reading other comments, having it be a forced mount r/w is better.
(just like I have to force other FS to be mounted r/o instead of default
r/w)
--
Lab tests show that use of micro$oft causes cancer in lab animals