Bug 3301 - SMBFS Option error in stock RedHat kernels
Summary: SMBFS Option error in stock RedHat kernels
Keywords:
Status: CLOSED DUPLICATE of bug 3447
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: distribution
Version: 6.0
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-06-06 15:13 UTC by Michael H. Warfield
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-06-14 17:07:47 UTC
Embargoed:


Attachments (Terms of Use)

Description Michael H. Warfield 1999-06-06 15:13:11 UTC
I'm the maintainer of smbmount in the Samba package.
Lately I've noticed a significant increase in reports of a
specific, very peculiar, problem with smbfs where timestamps
of files are corrupted.  These occur on Windows NT, Windows
2000, and Windows 98 shares.  The problem occurs whenever
the Windows 95 Bug Workaround is enabled in kernel builds
and those kernels are then used to mount shares from
something other than Windows 95.

        Inspection of the kernel source packages on the
RedHat 6.0 source disk revealed that the stock x86 and
sparc kernels are all being built with this option enabled.
Since this is the first RedHat build with the 2.2.x kernels
and, subsequently, the first build with the Samba version of
smbmount, this problem is only just recently becoming
chronic.  Up until now, people wishing to use the 2.2.x
kernels with the newer smbfs module and the newer smbmount
would have to build their own.  Often, they would not
include this option and the problem would not occur.  Now,
with this option enabled in stock kernels, the complaint
level is rising.


] # grep  SMB_WIN95 *.config
] kernel-2.2-i386-BOOT.config:CONFIG_SMB_WIN95=y
] kernel-2.2-i386-smp.config:CONFIG_SMB_WIN95=y
] kernel-2.2-i386.config:CONFIG_SMB_WIN95=y
] kernel-2.2-i586-smp.config:CONFIG_SMB_WIN95=y
] kernel-2.2-i586.config:CONFIG_SMB_WIN95=y
] kernel-2.2-i686-smp.config:CONFIG_SMB_WIN95=y
] kernel-2.2-i686.config:CONFIG_SMB_WIN95=y
] kernel-2.2-sparc-smp.config:CONFIG_SMB_WIN95=y
] kernel-2.2-sparc.config:CONFIG_SMB_WIN95=y
] kernel-2.2-sparc64-smp.config:CONFIG_SMB_WIN95=y
] kernel-2.2-sparc64.config:CONFIG_SMB_WIN95=y


        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.  Specifically, it causes the bytes in the
file timestamps to be reversed.  The results in timestamps
which appear to be garbage.  Attempts to use timestamp
dependent utilities (such as Make) result in random acts
of terrorism and errors.

        The Windows 95 Bug Workaround should be enabled in
the kernel build IF AND ONLY IF all of the shares which will
be mounted by smbfs are only and will only ever be from
Windows 95 systems.  If there is any chance that a share
from a Windows NT, Windows 2000, or Windows 98 system may be
mounted by smbfs, the Windows 95 Bug Workaround option in
the kernel build MUST NOT BE ENABLED!

        Please correct this error in your kernel builds...


        I plan on posting messages to the Samba mailing list
(samba), the Linux Kernel mailing list
(linux-kernel.edu) and to the RedHat List
(redhat-list) shortly announcing this problem.
This message is to give you a chance, in advance to correct
the problem and to be prepared with a response to the
announcement.

	I have marked this as a high priority problem due
to the fact that it can cause corruption of timestamps in
file systems.  Copying files which have been corrupted in
this way can cause propagation of bad timestamps (and the
problems they create) to other file systems.

Comment 1 Bill Nottingham 1999-06-14 17:07:59 UTC
*** This bug has been marked as a duplicate of 3447 ***


Note You need to log in before you can comment on or make changes to this bug.