A non-text attachment was scrubbed... Name: not available Type: text Size: 570 bytes Desc: not available Url : http://lists.samba.org/archive/samba/attachments/19990609/78775f4b/attachment.bat
On Wed, Jun 09, 1999 at 11:31:45AM -0400, Michael H. Warfield wrote:> The Windows 95 Bug Workaround forces "ON" some protocol > hacks to work around bugs in Windows 95. The code for this hack > is in the kernel even if this option is disabled. If the option > is disabled, the bug workaround is "OFF" by default but can be > enabled with a mount time option. If the Windows 95 Bug Workaround > is enabled when the kernel is compiled, this code is forced "ON" > with no way to disable it. This code is strictly for Windows 95 > shares and causes havoc with Windows NT, Windows 2000, and Windows 98 > shares.Then surely this option should be removed from the makefiles immediately. Why does this option exist at all? (Apart from hysterical raisons, which don't count.) -- Matthew Wilcox <willy@bofh.ai> "Windows and MacOS are products, contrived by engineers in the service of specific companies. Unix, by contrast, is not so much a product as it is a painstakingly compiled oral history of the hacker subculture." - N Stephenson
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).> AlanMike -- Michael H. Warfield | (770) 985-6132 | mhw@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!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Um, quite frankly, why would anyone use the stock kernel anyway? The point of the stock kernel is to get the system running well enough to get a custom compiled kernel, IMHO. Besides, the stock kernel for RH 6.0 isn't all that good anyway - I get TONS better performance on my own compiled kernels... and not NEARLY as much space in modules. On Wed, 9 Jun 1999, Michael H. Warfield wrote:> Ok... I reported this problem to RedHat several days > ago, so they have had at least a small chance to look it over and > be ready for this announcement. I'm continuing to hear complaints > about corrupted timestamps on smbfs mounts so this word needs to > get out. >- ------------------------------------------------------------------------ Michael B. Trausch President of Linux Operations, ADK Computers http://adk.hypermart.net/ - ------------------------------------------------------------------------ PGP Public Key is available at a Key Server near you, or at: http://wcnet.org/~mtrausch/pubkey.txt - ------------------------------------------------------------------------ ADK Computers, Walbridge Office E-Mail: mtrausch@wcnet.org - ------------------------------------------------------------------------ To fall in love is to create a religion that has a fallible god. - JLB Life is a comedy for those who think and a tragedy for those who feel. Love is friendship set on fire. - French Proverb Customer: I'm running Windows '98 Tech: Yes. Customer: My computer isn't working now. Tech: Yes, you said that. -----BEGIN PGP SIGNATURE----- Version: GnuPG v0.9.7 (GNU/Linux) Comment: Made with PGP4Pine iD8DBQE3XsL0BtYAauOptokRAs9BAJ9/3fy9MbmiBAJFeA58Erp/ZBOJbACfdPzY LJJyegyWgtLv2+SoNisvZ6I=K5Vx -----END PGP SIGNATURE-----
alan:
The real big problem is that the WIN95 workaround isnt a mount option.
But it is. The bug is that the kernel has a CONFIG_SMB_WIN95
that overrules the mount option. Just delete all mention of CONFIG_SMB_WIN95
from the kernel source (that is, from fs/Config.in, fs/smbfs/inode.c
and Documentation/Configure.help, Documentation/filesystems/smbfs.txt)
and all will be well.
Andries
Alan, 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.> The real big problem is that the WIN95 workaround isnt a mount option. Or > better yet autodetected.One other point about this... While there is a mount option (ugly), the mount option is totally inoperative when the compile option is enabled (yes, I had a slight typo in my previous message where I said enabled twice). Even IF I put the code into smbmount to autodetect the Windows 95 connections (which I want to do), the user space program can not override that compile option if it's enabled. If the compile option is disabled, I can set or clear that "feature" on a mount-by-mount, connection-by-connection, basis. As long as that option is enabled in the build, I'm screwed. I can't do anything from user space to correct the problem.> AlanMike -- Michael H. Warfield | (770) 985-6132 | mhw@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!
A non-text attachment was scrubbed... Name: not available Type: text Size: 605 bytes Desc: not available Url : http://lists.samba.org/archive/samba/attachments/19990609/ff04b401/attachment.bat
Bernhard Rosenkraenzer
1999-Jun-10 04:24 UTC
Do not use stock RedHat 6.0 kernels with SMBFS!
On Wed, 9 Jun 1999, Michael H. Warfield wrote:> Ok... I reported this problem to RedHat several days > ago, so they have had at least a small chance to look it over and > be ready for this announcement. I'm continuing to hear complaints > about corrupted timestamps on smbfs mounts so this word needs to > get out.We have had a look at the problem and noticed Mandrake 6.0 is affected, too. We've made fixed kernel RPMs available. They'll be available at ftp://sunsite.uio.no/pub/linux/Mandrake/updates/6.0/kernel*25mdk.i586.rpm and all other mirrors shortly (presently uploading). LLaP bero