Do not use stock RedHat 6.0 kernels with SMBFS!

[Michael H. Warfield]

Alan Cox enscribed thusly:
> > 	This problem may also have been present with the SMBFS module
> > and smbmount program from the 2.0 kernels.  Since I do not maintain
> > that version of smbmount, I'm unaware if the problem existed in those
> > earlier versions or not.

> As far as I am aware Red Hat, and most of the other vendors ship with the
> win95 work around enabled as that (at least was) the normal platform, and
> crashing win95 boxes would give Linux a bad name, even if it wasnt Linux
> fault.

	Hmmm...  Crashing Windows 95 SERVERS sounds like a feature to me.

	I'm really not sure what's worse.  The reputation if we crash
Windows 95 when it's used as a server (YUCK) or the reputation we get
when the file systems appear to be corrupted with REAL SERVERS (not
counting Windows 98 in the real servers category, but you get what I mean).

	Maybe we should have two options.  One being the Windows 95 slow
down the protocol option to prevent us from nuking Windows 95 boxes
because they can't handle the timing.  The other being a Windows 95
inane byte bass ackards option to fix timestamps.  Actually, the correct
fix is to get the $#@$#@ autodetect in, I know.

> The real big problem is that the WIN95 workaround isnt a mount option. Or
> better yet autodetected.

	Wwweeelll...  Actually it is, but it's a gross ugly hack and I have
no clue who did it.  If you look in the smbfs code you find that it checks
one of the bits in the file mode (the sticky bit I think) and flips on the
WIN95 bug workaround based on that.  It's in this little stretch of code
in fs/smbfs/inode.c:

========================================================
        /* ** temp ** pass config flags in file mode */
        mnt->version = (mnt->file_mode >> 9);
#ifdef CONFIG_SMB_WIN95
        mnt->version |= SMB_FIX_WIN95;
#endif
========================================================

	So SMB_FIX_WIN95 is defined as 1 so that means that bit 9 of the
file mode becomes that SMB_FIX_WIN95 flag in the version element of that
mount structure.  So you turn it on with a -f 1xxx in the file mode.  The
CONFIG_SMB_WIN95 merely forces that bit on for each and EVERY smbfs mount.
It would have been one hell of a lot better if that had been an XOR so we
at least had the ability to disable it using the gross ugly hack.

	The rest of the code merely checks the SMB_FIX_WIN95 bit in the
version field for switching those options, so it all follows from the
file permissions and then the compile option.

	Now don't hit me!  I didn't do it!  I'm not responsible for that
module!  :-)

	I was going to add a -9 option to smbmount to "or" that flag
in.  I figure I could have gotten away with adding the option and telling
everyone about the option without telling them that it was just and interface
to a gross ugly hack and get away with it...  Oh well...

	With the compile option enabled, you have no way to disable it.
With the compile option enabled, you CAN enable or disable it on a mount
by mount basis, it just isn't pretty.

	Tridge and Luke and I did discuss something about an autodetect.
I just haven't gotten around to figuring out if it belongs in the smbmount
program (likely) and passed down to smbfs in the gross ugly hack field or
if it belongs in smbfs to figure out and we can do away with the gross ugly
hack.  It probably should be detected in smbmount and passed through in
it's own structure element, but that means changing that interface AGAIN!

	Tridge and Luke and John and the rest of the Samba team don't want
to go near that module.  That's why I ended up on the team dealing with
smbmount.  And maintainership of smbfs did not go along with maintainership
of smbmount.

	BTW...  The MAINTAINERS file is also wrong in the kernel sources.
Volker is no longer maintaining smbfs (and hasn't for a long time) and the
Samba mailing list was never the mailing list for smbfs (I just found out
that it was listed there).

> Alan

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw at WittsEnd.com
  (The Mad Wizard)      |  (770) 925-8248   |  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!