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.
*** 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
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
(firstname.lastname@example.org), the Linux Kernel mailing list
(email@example.com) and to the RedHat List
(firstname.lastname@example.org) 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.
fixed in kernel-2.2.5-23, which will go out with the next
Raw Hide release.
*** 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
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.
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