Bug 3447 - Kernel compiled with CONFIG_SMB_WIN95
Kernel compiled with CONFIG_SMB_WIN95
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Lawrence
: 3301 3880 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 1999-06-14 03:40 EDT by Hermann Schichl
Modified: 2008-05-01 11:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 1999-06-15 10:45:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Hermann Schichl 1999-06-14 03:40:45 EDT
The kernels from package 2.2.5-22 are incorrectly
compiled with CONFIG_SMB_WIN95, which causes timestamp
curruption in Win98 and WinNT when using smbfs.

It would be better to compile w/o CONFIG_SMB_WIN95
and specify Win95 bug workaround at mount-time.
Comment 1 Bill Nottingham 1999-06-14 13:07:59 EDT
*** Bug 3301 has been marked as a duplicate of this bug. ***

        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@samba.org), the Linux Kernel mailing list
(linux-kernel@vger.rutgers.edu) and to the RedHat List
(redhat-list@redhat.com) 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

	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 2 Bill Nottingham 1999-06-15 10:45:59 EDT
fixed in kernel-2.2.5-23, which will go out with the next
Raw Hide release.
Comment 3 Bill Nottingham 1999-07-06 10:57:59 EDT
*** Bug 3880 has been marked as a duplicate of this bug. ***

I am running Samba 2.0.3-8 as distributed on the RedHat 6.0

First problem: apparently someone changed the syntax of
smbmount. Well, that broke a number of scripts. I fixed
them, so it is no major problem.

Second problem: when I mount my NT Server/Workstation disk,
all seems to be OK, but an ls -l listing produces dates
that are incorrect.
I am running NT 4.0 Service Pack 5.  An example of an
incorrect ls listing follows. Note, the dates should
correspond to the dates in the filename. Not more than 10
minutes ago, I wrote the file pmatouPartion03Jul1999, yet
in the ls listing, it has the date Aug 5 1998. It even
thinks that we have dates in 2021 !

The NT disk is mounted on the Linux machine with the
following commands:

smbmount \\\\minou\\ntd$ -c 'mount /mnt/ntd$'

Note, if I connect interactively with smbclient; cd to the
LinuxBackup directory and then do a dir, I get a listing
with the correct dates.

Best regards,

Kern Sibbald

ls l /mnt/ntd$/LinuxBackup
-rwxrwxr-x   1 root     root        13050 Jul 22  1983
-rwxrwxr-x   1 root     root     209565657 Jun 24  1944
-rwxrwxr-x   1 root     root     213245140 Mar 11  1968
-rwxrwxr-x   1 root     root     211174367 May 15  1994
-rwxrwxr-x   1 root     root     211190089 Dec 17  2018
-rwxrwxr-x   1 root     root     137461100 Dec  3  1997
-rwxrwxr-x   1 root     root        13536 Apr 14  1969
-rwxrwxr-x   1 root     root        26459 Jun 27  1998
-rwxrwxr-x   1 root     root        12599 Nov 17  1995
-rwxrwxr-x   1 root     root        26690 Jan 13  2021
-rwxrwxr-x   1 root     root        12580 May  4  1902
-rwxrwxr-x   1 root     root        12581 Feb  8  1927
-rwxrwxr-x   1 root     root        14106 Jan 21  1975
-rwxrwxr-x   1 root     root        14114 Aug 26  1996
-rwxrwxr-x   1 root     root        14293 Jul 27  2018
-rwxrwxr-x   1 root     root        14219 Jun  7  1903
-rwxrwxr-x   1 root     root        14514 Nov 19  1927
-rwxrwxr-x   1 root     root        14531 Sep 30  1950
-rwxrwxr-x   1 root     root        13353 Aug 17  1993
-rwxrwxr-x   1 root     root        13355 Nov 10  2015
-rwxrwxr-x   1 root     root        13356 Apr 22  1902
-rwxrwxr-x   1 root     root        13355 Mar  4  1925
-rwxrwxr-x   1 root     root        13355 May 28  1947
-rwxrwxr-x   1 root     root        13355 Apr  8  1970
-rwxrwxr-x   1 root     root        13398 Sep 25  2014
-rwxrwxr-x   1 root     root        13404 Oct  7  1902
-rwxrwxr-x   1 root     root        13405 Sep  5  1924
-rwxrwxr-x   1 root     root        13405 Jul 19  1947
-rwxrwxr-x   1 root     root        13434 Dec 16  1992
-rwxrwxr-x   1 root     root        13535 Apr 10  1902
-rwxrwxr-x   1 root     root        13535 Feb 20  1925
-rwxrwxr-x   1 root     root        13536 Apr  9  1949
-rwxrwxr-x   1 root     root     83416829 Feb  3  1957
-rwxrwxr-x   1 root     root        16053 Aug  5  1998

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